mirror of https://github.com/python/cpython
A lot more typo fixes by Ori Avtalion.
This commit is contained in:
parent
a14a4e8b84
commit
907a720f89
|
@ -174,6 +174,6 @@ Long Integer Objects
|
|||
.. versionadded:: 1.5.2
|
||||
|
||||
.. versionchanged:: 2.5
|
||||
For values outside 0..LONG_MAX, both signed and unsigned integers are acccepted.
|
||||
For values outside 0..LONG_MAX, both signed and unsigned integers are accepted.
|
||||
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@ Buffer Protocol
|
|||
|
||||
.. cfunction:: int PyObject_AsCharBuffer(PyObject *obj, const char **buffer, Py_ssize_t *buffer_len)
|
||||
|
||||
Returns a pointer to a read-only memory location useable as character- based
|
||||
Returns a pointer to a read-only memory location usable as character-based
|
||||
input. The *obj* argument must support the single-segment character buffer
|
||||
interface. On success, returns ``0``, sets *buffer* to the memory location and
|
||||
*buffer_len* to the buffer length. Returns ``-1`` and sets a :exc:`TypeError`
|
||||
|
|
|
@ -573,7 +573,7 @@ The following three fields only exist if the
|
|||
The :attr:`tp_traverse` pointer is used by the garbage collector to detect
|
||||
reference cycles. A typical implementation of a :attr:`tp_traverse` function
|
||||
simply calls :cfunc:`Py_VISIT` on each of the instance's members that are Python
|
||||
objects. For exampe, this is function :cfunc:`local_traverse` from the
|
||||
objects. For example, this is function :cfunc:`local_traverse` from the
|
||||
:mod:`thread` extension module::
|
||||
|
||||
static int
|
||||
|
@ -1160,7 +1160,7 @@ Number Object Structures
|
|||
binaryfunc nb_and;
|
||||
binaryfunc nb_xor;
|
||||
binaryfunc nb_or;
|
||||
coercion nb_coerce; /* Used by the coerce() funtion */
|
||||
coercion nb_coerce; /* Used by the coerce() function */
|
||||
unaryfunc nb_int;
|
||||
unaryfunc nb_long;
|
||||
unaryfunc nb_float;
|
||||
|
|
|
@ -195,7 +195,7 @@ Distutils configuration files. Various options and sections in the
|
|||
| | or --- & :option:`maintainer` and |
|
||||
| | :option:`maintainer_email` |
|
||||
+------------------------------------------+----------------------------------------------+
|
||||
| Copyright | :option:`licence` |
|
||||
| Copyright | :option:`license` |
|
||||
+------------------------------------------+----------------------------------------------+
|
||||
| Url | :option:`url` |
|
||||
+------------------------------------------+----------------------------------------------+
|
||||
|
|
|
@ -53,13 +53,13 @@ the web interface.
|
|||
The .pypirc file
|
||||
================
|
||||
|
||||
The format of the :file:`.pypirc` file is formated as follows::
|
||||
The format of the :file:`.pypirc` file is as follows::
|
||||
|
||||
[server-login]
|
||||
repository: <repository-url>
|
||||
username: <username>
|
||||
password: <password>
|
||||
|
||||
*repository* can be ommitted and defaults to ``http://www.python.org/pypi``.
|
||||
*repository* can be omitted and defaults to ``http://www.python.org/pypi``.
|
||||
|
||||
|
||||
|
|
|
@ -276,7 +276,7 @@ language, but it boils down to three conditions:
|
|||
product in any way.
|
||||
|
||||
* If something goes wrong, you can't sue for damages. Practically all software
|
||||
licences contain this condition.
|
||||
licenses contain this condition.
|
||||
|
||||
Notice that you don't have to provide source code for anything that contains
|
||||
Python or is built with it. Also, the Python interpreter and accompanying
|
||||
|
|
|
@ -114,7 +114,7 @@ from module import name1, name2
|
|||
This is a "don't" which is much weaker then the previous "don't"s but is still
|
||||
something you should not do if you don't have good reasons to do that. The
|
||||
reason it is usually bad idea is because you suddenly have an object which lives
|
||||
in two seperate namespaces. When the binding in one namespace changes, the
|
||||
in two separate namespaces. When the binding in one namespace changes, the
|
||||
binding in the other will not, so there will be a discrepancy between them. This
|
||||
happens when, for example, one module is reloaded, or changes the definition of
|
||||
a function at runtime.
|
||||
|
|
|
@ -905,7 +905,7 @@ returns them in a tuple::
|
|||
itertools.izip(['a', 'b', 'c'], (1, 2, 3)) =>
|
||||
('a', 1), ('b', 2), ('c', 3)
|
||||
|
||||
It's similiar to the built-in :func:`zip` function, but doesn't construct an
|
||||
It's similar to the built-in :func:`zip` function, but doesn't construct an
|
||||
in-memory list and exhaust all the input iterators before returning; instead
|
||||
tuples are constructed and returned only if they're requested. (The technical
|
||||
term for this behaviour is `lazy evaluation
|
||||
|
|
|
@ -357,7 +357,7 @@ thing to do - give it a nice long timeout (say a minute) unless you have good
|
|||
reason to do otherwise.
|
||||
|
||||
In return, you will get three lists. They have the sockets that are actually
|
||||
readable, writable and in error. Each of these lists is a subset (possbily
|
||||
readable, writable and in error. Each of these lists is a subset (possibly
|
||||
empty) of the corresponding list you passed in. And if you put a socket in more
|
||||
than one input list, it will only be (at most) in one output list.
|
||||
|
||||
|
@ -371,7 +371,7 @@ just means outbound network buffer space is available.)
|
|||
If you have a "server" socket, put it in the potential_readers list. If it comes
|
||||
out in the readable list, your ``accept`` will (almost certainly) work. If you
|
||||
have created a new socket to ``connect`` to someone else, put it in the
|
||||
ptoential_writers list. If it shows up in the writable list, you have a decent
|
||||
potential_writers list. If it shows up in the writable list, you have a decent
|
||||
chance that it has connected.
|
||||
|
||||
One very nasty problem with ``select``: if somewhere in those input lists of
|
||||
|
|
|
@ -1001,7 +1001,7 @@ particular, the following variants typically exist:
|
|||
+-----------------+--------------------------------+--------------------------------+
|
||||
| iso8859_3 | iso-8859-3, latin3, L3 | Esperanto, Maltese |
|
||||
+-----------------+--------------------------------+--------------------------------+
|
||||
| iso8859_4 | iso-8859-4, latin4, L4 | Baltic languagues |
|
||||
| iso8859_4 | iso-8859-4, latin4, L4 | Baltic languages |
|
||||
+-----------------+--------------------------------+--------------------------------+
|
||||
| iso8859_5 | iso-8859-5, cyrillic | Bulgarian, Byelorussian, |
|
||||
| | | Macedonian, Russian, Serbian |
|
||||
|
|
|
@ -470,7 +470,7 @@ they add the ability to access fields by name instead of position index.
|
|||
.. function:: namedtuple(typename, fieldnames, [verbose])
|
||||
|
||||
Returns a new tuple subclass named *typename*. The new subclass is used to
|
||||
create tuple-like objects that have fields accessable by attribute lookup as
|
||||
create tuple-like objects that have fields accessible by attribute lookup as
|
||||
well as being indexable and iterable. Instances of the subclass also have a
|
||||
helpful docstring (with typename and fieldnames) and a helpful :meth:`__repr__`
|
||||
method which lists the tuple contents in a ``name=value`` format.
|
||||
|
@ -536,7 +536,7 @@ Example::
|
|||
>>> x, y = p # unpack like a regular tuple
|
||||
>>> x, y
|
||||
(11, 22)
|
||||
>>> p.x + p.y # fields also accessable by name
|
||||
>>> p.x + p.y # fields also accessible by name
|
||||
33
|
||||
>>> p # readable __repr__ with a name=value style
|
||||
Point(x=11, y=22)
|
||||
|
|
|
@ -1609,7 +1609,7 @@ of significant places in the coefficient. For example, expressing
|
|||
original's two-place significance.
|
||||
|
||||
If an application does not care about tracking significance, it is easy to
|
||||
remove the exponent and trailing zeroes, losing signficance, but keeping the
|
||||
remove the exponent and trailing zeroes, losing significance, but keeping the
|
||||
value unchanged::
|
||||
|
||||
>>> def remove_exponent(d):
|
||||
|
|
|
@ -43,7 +43,7 @@ can include messages from third-party modules.
|
|||
It is, of course, possible to log messages with different verbosity levels or to
|
||||
different destinations. Support for writing log messages to files, HTTP
|
||||
GET/POST locations, email via SMTP, generic sockets, or OS-specific logging
|
||||
mechnisms are all supported by the standard module. You can also create your
|
||||
mechanisms are all supported by the standard module. You can also create your
|
||||
own log destination class if you have special requirements not met by any of the
|
||||
built-in classes.
|
||||
|
||||
|
@ -267,7 +267,7 @@ destination. Logger objects can add zero or more handler objects to themselves
|
|||
with an :func:`addHandler` method. As an example scenario, an application may
|
||||
want to send all log messages to a log file, all log messages of error or higher
|
||||
to stdout, and all messages of critical to an email address. This scenario
|
||||
requires three individual handlers where each hander is responsible for sending
|
||||
requires three individual handlers where each handler is responsible for sending
|
||||
messages of a specific severity to a specific location.
|
||||
|
||||
The standard library includes quite a few handler types; this tutorial uses only
|
||||
|
|
|
@ -433,7 +433,7 @@ the original. In the interest of compatibility, :class:`mbox` implements the
|
|||
original format, which is sometimes referred to as :dfn:`mboxo`. This means that
|
||||
the :mailheader:`Content-Length` header, if present, is ignored and that any
|
||||
occurrences of "From " at the beginning of a line in a message body are
|
||||
transformed to ">From " when storing the message, although occurences of ">From
|
||||
transformed to ">From " when storing the message, although occurrences of ">From
|
||||
" are not transformed to "From " when reading the message.
|
||||
|
||||
Some :class:`Mailbox` methods implemented by :class:`mbox` deserve special
|
||||
|
@ -581,7 +581,7 @@ remarks:
|
|||
|
||||
.. method:: MH.close()
|
||||
|
||||
:class:`MH` instances do not keep any open files, so this method is equivelant
|
||||
:class:`MH` instances do not keep any open files, so this method is equivalent
|
||||
to :meth:`unlock`.
|
||||
|
||||
|
||||
|
|
|
@ -245,7 +245,7 @@ Unix Platforms
|
|||
version)`` which default to the given parameters in case the lookup fails.
|
||||
|
||||
Note that this function has intimate knowledge of how different libc versions
|
||||
add symbols to the executable is probably only useable for executables compiled
|
||||
add symbols to the executable is probably only usable for executables compiled
|
||||
using :program:`gcc`.
|
||||
|
||||
The file is read and scanned in chunks of *chunksize* bytes.
|
||||
|
|
|
@ -531,7 +531,7 @@ The :class:`Stats` Class
|
|||
non-parenthesized number repeats the cumulative time spent in the function
|
||||
at the right.
|
||||
|
||||
* With :mod:`cProfile`, each caller is preceeded by three numbers: the number of
|
||||
* With :mod:`cProfile`, each caller is preceded by three numbers: the number of
|
||||
times this specific call was made, and the total and cumulative times spent in
|
||||
the current function while it was invoked by this specific caller.
|
||||
|
||||
|
|
|
@ -98,7 +98,7 @@ Bookkeeping functions:
|
|||
Change the internal state to one different from and likely far away from the
|
||||
current state. *n* is a non-negative integer which is used to scramble the
|
||||
current state vector. This is most useful in multi-threaded programs, in
|
||||
conjuction with multiple instances of the :class:`Random` class:
|
||||
conjunction with multiple instances of the :class:`Random` class:
|
||||
:meth:`setstate` or :meth:`seed` can be used to force all instances into the
|
||||
same internal state, and then :meth:`jumpahead` can be used to force the
|
||||
instances' states far apart.
|
||||
|
|
|
@ -1102,7 +1102,7 @@ into a list with each nonempty line having its own entry::
|
|||
'Heather Albrecht 548.326.4584 919 Park Place']
|
||||
|
||||
Finally, split each entry into a list with first name, last name, telephone
|
||||
number, and address. We use the ``maxsplit`` paramater of :func:`split`
|
||||
number, and address. We use the ``maxsplit`` parameter of :func:`split`
|
||||
because the address has spaces, our splitting pattern, in it::
|
||||
|
||||
>>> [re.split(":? ", entry, 3) for entry in entries]
|
||||
|
@ -1112,7 +1112,7 @@ because the address has spaces, our splitting pattern, in it::
|
|||
['Heather', 'Albrecht', '548.326.4584', '919 Park Place']]
|
||||
|
||||
The ``:?`` pattern matches the colon after the last name, so that it does not
|
||||
occur in the result list. With a ``maxsplit`` of ``4``, we could seperate the
|
||||
occur in the result list. With a ``maxsplit`` of ``4``, we could separate the
|
||||
house number from the street name::
|
||||
|
||||
>>> [re.split(":? ", entry, 4) for entry in entries]
|
||||
|
@ -1144,7 +1144,7 @@ in each word of a sentence except for the first and last characters::
|
|||
Finding all Adverbs
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
:func:`findall` matches *all* occurences of a pattern, not just the first
|
||||
:func:`findall` matches *all* occurrences of a pattern, not just the first
|
||||
one as :func:`search` does. For example, if one was a writer and wanted to
|
||||
find all of the adverbs in some text, he or she might use :func:`findall` in
|
||||
the following manner::
|
||||
|
|
|
@ -929,5 +929,5 @@ the interface::
|
|||
# receive a package
|
||||
print s.recvfrom(65565)
|
||||
|
||||
# disabled promiscous mode
|
||||
# disabled promiscuous mode
|
||||
s.ioctl(socket.SIO_RCVALL, socket.RCVALL_OFF)
|
||||
|
|
|
@ -18,7 +18,7 @@ The primary entry point is a :term:`generator`:
|
|||
|
||||
.. function:: generate_tokens(readline)
|
||||
|
||||
The :func:`generate_tokens` generator requires one argment, *readline*, which
|
||||
The :func:`generate_tokens` generator requires one argument, *readline*, which
|
||||
must be a callable object which provides the same interface as the
|
||||
:meth:`readline` method of built-in file objects (see section
|
||||
:ref:`bltin-file-objects`). Each call to the function should return one line of
|
||||
|
|
|
@ -421,7 +421,7 @@ TreeBuilder Objects
|
|||
|
||||
.. method:: TreeBuilder.close()
|
||||
|
||||
Flushes the parser buffers, and returns the toplevel documen element. Returns an
|
||||
Flushes the parser buffers, and returns the toplevel document element. Returns an
|
||||
Element instance.
|
||||
|
||||
|
||||
|
|
|
@ -531,7 +531,7 @@ implementation details.
|
|||
|
||||
.. rubric:: Footnotes
|
||||
|
||||
.. [#] The exception is propogated to the invocation stack only if there is no
|
||||
.. [#] The exception is propagated to the invocation stack only if there is no
|
||||
:keyword:`finally` clause that negates the exception.
|
||||
|
||||
.. [#] Currently, control "flows off the end" except in the case of an exception or the
|
||||
|
|
|
@ -395,7 +395,7 @@ generator function:
|
|||
generator, or raises :exc:`StopIteration` if the generator exits without
|
||||
yielding another value. When :meth:`send` is called to start the generator, it
|
||||
must be called with :const:`None` as the argument, because there is no
|
||||
:keyword:`yield` expression that could receieve the value.
|
||||
:keyword:`yield` expression that could receive the value.
|
||||
|
||||
|
||||
.. method:: generator.throw(type[, value[, traceback]])
|
||||
|
@ -677,7 +677,7 @@ there were no excess keyword arguments.
|
|||
|
||||
If the syntax ``*expression`` appears in the function call, ``expression`` must
|
||||
evaluate to a sequence. Elements from this sequence are treated as if they were
|
||||
additional positional arguments; if there are postional arguments *x1*,...,*xN*
|
||||
additional positional arguments; if there are positional arguments *x1*,...,*xN*
|
||||
, and ``expression`` evaluates to a sequence *y1*,...,*yM*, this is equivalent
|
||||
to a call with M+N positional arguments *x1*,...,*xN*,*y1*,...,*yM*.
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ write a Python extension module, and the :ref:`c-api-index` describes the
|
|||
interfaces available to C/C++ programmers in detail.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
:maxdepth: 2
|
||||
|
||||
introduction.rst
|
||||
lexical_analysis.rst
|
||||
|
|
|
@ -560,7 +560,7 @@ doing ``isinstance(obj, Number)``.
|
|||
Numbers are further divided into :class:`Exact` and :class:`Inexact`.
|
||||
Exact numbers can represent values precisely and operations never
|
||||
round off the results or introduce tiny errors that may break the
|
||||
communtativity and associativity properties; inexact numbers may
|
||||
commutativity and associativity properties; inexact numbers may
|
||||
perform such rounding or introduce small errors. Integers, long
|
||||
integers, and rational numbers are exact, while floating-point
|
||||
and complex numbers are inexact.
|
||||
|
@ -1395,7 +1395,7 @@ Changes to Python's build process and to the C API include:
|
|||
.. Issue 1534
|
||||
|
||||
* Python's C API now includes two functions for case-insensitive string
|
||||
comparisions, ``PyOS_stricmp(char*, char*)``
|
||||
comparisons, ``PyOS_stricmp(char*, char*)``
|
||||
and ``PyOS_strnicmp(char*, char*, Py_ssize_t)``.
|
||||
(Contributed by Christian Heimes.)
|
||||
|
||||
|
|
Loading…
Reference in New Issue