mirror of https://github.com/python/cpython
Merged revisions 74209 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk ........ r74209 | georg.brandl | 2009-07-26 16:37:28 +0200 (So, 26 Jul 2009) | 1 line builtin -> built-in. ........
This commit is contained in:
parent
7a72b3ad7b
commit
22b3431426
|
@ -141,7 +141,7 @@ Importing Modules
|
|||
*path*, possibly by fetching it from the :data:`sys.path_importer_cache`
|
||||
dict. If it wasn't yet cached, traverse :data:`sys.path_hooks` until a hook
|
||||
is found that can handle the path item. Return ``None`` if no hook could;
|
||||
this tells our caller it should fall back to the builtin import mechanism.
|
||||
this tells our caller it should fall back to the built-in import mechanism.
|
||||
Cache the result in :data:`sys.path_importer_cache`. Return a new reference
|
||||
to the importer object.
|
||||
|
||||
|
|
|
@ -372,12 +372,12 @@ the system's :ctype:`wchar_t`.
|
|||
Built-in Codecs
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
Python provides a set of builtin codecs which are written in C for speed. All of
|
||||
Python provides a set of built-in codecs which are written in C for speed. All of
|
||||
these codecs are directly usable via the following functions.
|
||||
|
||||
Many of the following APIs take two arguments encoding and errors. These
|
||||
parameters encoding and errors have the same semantics as the ones of the
|
||||
builtin unicode() Unicode object constructor.
|
||||
built-in :func:`unicode` Unicode object constructor.
|
||||
|
||||
Setting encoding to *NULL* causes the default encoding to be used
|
||||
which is ASCII. The file system calls should use
|
||||
|
@ -389,7 +389,7 @@ pointer to a static string, on others, it will change at run-time
|
|||
|
||||
Error handling is set by errors which may also be set to *NULL* meaning to use
|
||||
the default handling defined for the codec. Default error handling for all
|
||||
builtin codecs is "strict" (:exc:`ValueError` is raised).
|
||||
built-in codecs is "strict" (:exc:`ValueError` is raised).
|
||||
|
||||
The codecs all use a similar interface. Only deviation from the following
|
||||
generic ones are documented for simplicity.
|
||||
|
@ -403,7 +403,7 @@ These are the generic codec APIs:
|
|||
|
||||
Create a Unicode object by decoding *size* bytes of the encoded string *s*.
|
||||
*encoding* and *errors* have the same meaning as the parameters of the same name
|
||||
in the :func:`unicode` builtin function. The codec to be used is looked up
|
||||
in the :func:`unicode` built-in function. The codec to be used is looked up
|
||||
using the Python codec registry. Return *NULL* if an exception was raised by
|
||||
the codec.
|
||||
|
||||
|
|
|
@ -1601,7 +1601,7 @@ lines, and joining lines with backslashes.
|
|||
+------------------+--------------------------------+---------+
|
||||
|
||||
Note that since *rstrip_ws* can strip the trailing newline, the semantics of
|
||||
:meth:`readline` must differ from those of the builtin file object's
|
||||
:meth:`readline` must differ from those of the built-in file object's
|
||||
:meth:`readline` method! In particular, :meth:`readline` returns ``None`` for
|
||||
end-of-file: an empty string might just be a blank line (or an all-whitespace
|
||||
line), if *rstrip_ws* is true but *skip_blanks* is not.
|
||||
|
@ -1609,8 +1609,8 @@ lines, and joining lines with backslashes.
|
|||
|
||||
.. method:: TextFile.open(filename)
|
||||
|
||||
Open a new file *filename*. This overrides any *file* or *filename* constructor
|
||||
arguments.
|
||||
Open a new file *filename*. This overrides any *file* or *filename*
|
||||
constructor arguments.
|
||||
|
||||
|
||||
.. method:: TextFile.close()
|
||||
|
|
|
@ -802,7 +802,7 @@ easily use the :class:`PyTypeObject` it needs. It can be difficult to share
|
|||
these :class:`PyTypeObject` structures between extension modules.
|
||||
|
||||
In this example we will create a :class:`Shoddy` type that inherits from the
|
||||
builtin :class:`list` type. The new type will be completely compatible with
|
||||
built-in :class:`list` type. The new type will be completely compatible with
|
||||
regular lists, but will have an additional :meth:`increment` method that
|
||||
increases an internal counter. ::
|
||||
|
||||
|
|
|
@ -28,11 +28,11 @@ Glossary
|
|||
|
||||
abstract base class
|
||||
Abstract Base Classes (abbreviated ABCs) complement :term:`duck-typing` by
|
||||
providing a way to define interfaces when other techniques like :func:`hasattr`
|
||||
would be clumsy. Python comes with many builtin ABCs for data structures
|
||||
(in the :mod:`collections` module), numbers (in the :mod:`numbers`
|
||||
module), and streams (in the :mod:`io` module). You can create your own
|
||||
ABC with the :mod:`abc` module.
|
||||
providing a way to define interfaces when other techniques like
|
||||
:func:`hasattr` would be clumsy. Python comes with many built-in ABCs for
|
||||
data structures (in the :mod:`collections` module), numbers (in the
|
||||
:mod:`numbers` module), and streams (in the :mod:`io` module). You can
|
||||
create your own ABC with the :mod:`abc` module.
|
||||
|
||||
argument
|
||||
A value passed to a function or method, assigned to a named local
|
||||
|
@ -83,7 +83,7 @@ Glossary
|
|||
expressed as a sum of a real part and an imaginary part. Imaginary
|
||||
numbers are real multiples of the imaginary unit (the square root of
|
||||
``-1``), often written ``i`` in mathematics or ``j`` in
|
||||
engineering. Python has builtin support for complex numbers, which are
|
||||
engineering. Python has built-in support for complex numbers, which are
|
||||
written with this latter notation; the imaginary part is written with a
|
||||
``j`` suffix, e.g., ``3+1j``. To get access to complex equivalents of the
|
||||
:mod:`math` module, use :mod:`cmath`. Use of complex numbers is a fairly
|
||||
|
@ -305,7 +305,7 @@ Glossary
|
|||
define with an :meth:`__iter__` or :meth:`__getitem__` method. Iterables
|
||||
can be used in a :keyword:`for` loop and in many other places where a
|
||||
sequence is needed (:func:`zip`, :func:`map`, ...). When an iterable
|
||||
object is passed as an argument to the builtin function :func:`iter`, it
|
||||
object is passed as an argument to the built-in function :func:`iter`, it
|
||||
returns an iterator for the object. This iterator is good for one pass
|
||||
over the set of values. When using iterables, it is usually not necessary
|
||||
to call :func:`iter` or deal with iterator objects yourself. The ``for``
|
||||
|
@ -409,7 +409,7 @@ Glossary
|
|||
|
||||
namespace
|
||||
The place where a variable is stored. Namespaces are implemented as
|
||||
dictionaries. There are the local, global and builtin namespaces as well
|
||||
dictionaries. There are the local, global and built-in namespaces as well
|
||||
as nested namespaces in objects (in methods). Namespaces support
|
||||
modularity by preventing naming conflicts. For instance, the functions
|
||||
:func:`builtins.open` and :func:`os.open` are distinguished by their
|
||||
|
|
|
@ -228,7 +228,7 @@ Compare::
|
|||
More useful functions in :mod:`os.path`: :func:`basename`, :func:`dirname` and
|
||||
:func:`splitext`.
|
||||
|
||||
There are also many useful builtin functions people seem not to be aware of for
|
||||
There are also many useful built-in functions people seem not to be aware of for
|
||||
some reason: :func:`min` and :func:`max` can find the minimum/maximum of any
|
||||
sequence with comparable semantics, for example, yet many people write their own
|
||||
:func:`max`/:func:`min`. Another highly useful function is
|
||||
|
|
|
@ -182,10 +182,9 @@ which comes after we have a look at what happens when things go wrong.
|
|||
Handling Exceptions
|
||||
===================
|
||||
|
||||
*urlopen* raises :exc:`URLError` when it cannot handle a response (though as usual
|
||||
with Python APIs, builtin exceptions such as
|
||||
:exc:`ValueError`, :exc:`TypeError` etc. may also
|
||||
be raised).
|
||||
*urlopen* raises :exc:`URLError` when it cannot handle a response (though as
|
||||
usual with Python APIs, built-in exceptions such as :exc:`ValueError`,
|
||||
:exc:`TypeError` etc. may also be raised).
|
||||
|
||||
:exc:`HTTPError` is the subclass of :exc:`URLError` raised in the specific case of
|
||||
HTTP URLs.
|
||||
|
|
|
@ -31,7 +31,7 @@ cur.execute("select ?", ("this is latin1 and would normally create errors" +
|
|||
row = cur.fetchone()
|
||||
assert type(row[0]) == str
|
||||
|
||||
# sqlite3 offers a builtin optimized text_factory that will return bytestring
|
||||
# sqlite3 offers a built-in optimized text_factory that will return bytestring
|
||||
# objects, if the data is in ASCII only, and otherwise return unicode objects
|
||||
con.text_factory = sqlite3.OptimizedUnicode
|
||||
cur.execute("select ?", (AUSTRIA,))
|
||||
|
|
|
@ -216,7 +216,7 @@ and off individually. They are described here in more detail.
|
|||
.. 2to3fixer:: itertools
|
||||
|
||||
Changes usage of :func:`itertools.ifilter`, :func:`itertools.izip`, and
|
||||
:func:`itertools.imap` to their builtin equivalents.
|
||||
:func:`itertools.imap` to their built-in equivalents.
|
||||
:func:`itertools.ifilterfalse` is changed to :func:`itertools.filterfalse`.
|
||||
|
||||
.. 2to3fixer:: long
|
||||
|
|
|
@ -52,7 +52,7 @@ Instances of class :class:`_Feature` have two corresponding methods,
|
|||
:meth:`getOptionalRelease` and :meth:`getMandatoryRelease`.
|
||||
|
||||
*CompilerFlag* is the (bitfield) flag that should be passed in the fourth
|
||||
argument to the builtin function :func:`compile` to enable the feature in
|
||||
argument to the built-in function :func:`compile` to enable the feature in
|
||||
dynamically compiled code. This flag is stored in the :attr:`compiler_flag`
|
||||
attribute on :class:`_Feature` instances.
|
||||
|
||||
|
|
|
@ -16,7 +16,7 @@ Python release; this module helps to find out programmatically what the current
|
|||
grammar looks like.
|
||||
|
||||
An abstract syntax tree can be generated by passing :data:`ast.PyCF_ONLY_AST` as
|
||||
a flag to the :func:`compile` builtin function, or using the :func:`parse`
|
||||
a flag to the :func:`compile` built-in function, or using the :func:`parse`
|
||||
helper provided in this module. The result will be a tree of objects whose
|
||||
classes all inherit from :class:`ast.AST`. An abstract syntax tree can be
|
||||
compiled into a Python code object using the built-in :func:`compile` function.
|
||||
|
|
|
@ -487,7 +487,7 @@ stack manipulations such as ``dup``, ``drop``, ``swap``, ``over``, ``pick``,
|
|||
.. class:: defaultdict([default_factory[, ...]])
|
||||
|
||||
Returns a new dictionary-like object. :class:`defaultdict` is a subclass of the
|
||||
builtin :class:`dict` class. It overrides one method and adds one writable
|
||||
built-in :class:`dict` class. It overrides one method and adds one writable
|
||||
instance variable. The remaining functionality is the same as for the
|
||||
:class:`dict` class and is not documented here.
|
||||
|
||||
|
|
|
@ -50,7 +50,7 @@ Default values can be specified by passing them into the :class:`ConfigParser`
|
|||
constructor as a dictionary. Additional defaults may be passed into the
|
||||
:meth:`get` method which will override all others.
|
||||
|
||||
Sections are normally stored in a builtin dictionary. An alternative dictionary
|
||||
Sections are normally stored in a built-in dictionary. An alternative dictionary
|
||||
type can be passed to the :class:`ConfigParser` constructor. For example, if a
|
||||
dictionary type is passed that sorts its keys, the sections will be sorted on
|
||||
write-back, as will be the keys within each section.
|
||||
|
|
|
@ -606,9 +606,9 @@ the following methods:
|
|||
.. note::
|
||||
|
||||
A *character* means a C character (an ASCII code), rather then a Python
|
||||
character (a string of length 1). (This note is true whenever the documentation
|
||||
mentions a character.) The builtin :func:`ord` is handy for conveying strings to
|
||||
codes.
|
||||
character (a string of length 1). (This note is true whenever the
|
||||
documentation mentions a character.) The built-in :func:`ord` is handy for
|
||||
conveying strings to codes.
|
||||
|
||||
Paint character *ch* at ``(y, x)`` with attributes *attr*, overwriting any
|
||||
character previously painter at that location. By default, the character
|
||||
|
|
|
@ -189,7 +189,7 @@ class can also install themselves in the built-in namespace as the function
|
|||
|
||||
.. function:: install(domain, localedir=None, codeset=None, names=None)
|
||||
|
||||
This installs the function :func:`_` in Python's builtin namespace, based on
|
||||
This installs the function :func:`_` in Python's builtins namespace, based on
|
||||
*domain*, *localedir*, and *codeset* which are passed to the function
|
||||
:func:`translation`.
|
||||
|
||||
|
@ -203,7 +203,7 @@ class can also install themselves in the built-in namespace as the function
|
|||
print(_('This string will be translated.'))
|
||||
|
||||
For convenience, you want the :func:`_` function to be installed in Python's
|
||||
builtin namespace, so it is easily accessible in all modules of your
|
||||
builtins namespace, so it is easily accessible in all modules of your
|
||||
application.
|
||||
|
||||
|
||||
|
@ -294,7 +294,7 @@ are the methods of :class:`NullTranslations`:
|
|||
binding it to ``_``.
|
||||
|
||||
If the *names* parameter is given, it must be a sequence containing the
|
||||
names of functions you want to install in the builtin namespace in
|
||||
names of functions you want to install in the builtins namespace in
|
||||
addition to :func:`_`. Supported names are ``'gettext'`` (bound to
|
||||
:meth:`self.gettext`), ``'ngettext'`` (bound to :meth:`self.ngettext`),
|
||||
``'lgettext'`` and ``'lngettext'``.
|
||||
|
|
|
@ -134,7 +134,7 @@ The module also offers three general purpose functions based on heaps.
|
|||
|
||||
The latter two functions perform best for smaller values of *n*. For larger
|
||||
values, it is more efficient to use the :func:`sorted` function. Also, when
|
||||
``n==1``, it is more efficient to use the builtin :func:`min` and :func:`max`
|
||||
``n==1``, it is more efficient to use the built-in :func:`min` and :func:`max`
|
||||
functions.
|
||||
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@
|
|||
.. sectionauthor:: Benjamin Peterson <benjamin@python.org>
|
||||
|
||||
The :mod:`io` module provides the Python interfaces to stream handling. The
|
||||
builtin :func:`open` function is defined in this module.
|
||||
built-in :func:`open` function is defined in this module.
|
||||
|
||||
At the top of the I/O hierarchy is the abstract base class :class:`IOBase`. It
|
||||
defines the basic interface to a stream. Note, however, that there is no
|
||||
|
|
|
@ -1554,9 +1554,9 @@ with the :class:`Pool` class.
|
|||
.. method:: apply(func[, args[, kwds]])
|
||||
|
||||
Call *func* with arguments *args* and keyword arguments *kwds*. It blocks
|
||||
till the result is ready. Given this blocks - :meth:`apply_async` is better suited
|
||||
for performing work in parallel. Additionally, the passed
|
||||
in function is only executed in one of the workers of the pool.
|
||||
till the result is ready. Given this blocks, :meth:`apply_async` is better
|
||||
suited for performing work in parallel. Additionally, the passed in
|
||||
function is only executed in one of the workers of the pool.
|
||||
|
||||
.. method:: apply_async(func[, args[, kwds[, callback]]])
|
||||
|
||||
|
@ -1569,7 +1569,7 @@ with the :class:`Pool` class.
|
|||
|
||||
.. method:: map(func, iterable[, chunksize])
|
||||
|
||||
A parallel equivalent of the :func:`map` builtin function (it supports only
|
||||
A parallel equivalent of the :func:`map` built-in function (it supports only
|
||||
one *iterable* argument though). It blocks till the result is ready.
|
||||
|
||||
This method chops the iterable into a number of chunks which it submits to
|
||||
|
|
|
@ -22,7 +22,7 @@ The numeric tower
|
|||
.. class:: Complex
|
||||
|
||||
Subclasses of this type describe complex numbers and include the operations
|
||||
that work on the builtin :class:`complex` type. These are: conversions to
|
||||
that work on the built-in :class:`complex` type. These are: conversions to
|
||||
:class:`complex` and :class:`bool`, :attr:`.real`, :attr:`.imag`, ``+``,
|
||||
``-``, ``*``, ``/``, :func:`abs`, :meth:`conjugate`, ``==``, and ``!=``. All
|
||||
except ``-`` and ``!=`` are abstract.
|
||||
|
|
|
@ -13,7 +13,7 @@ Python data structures in a form which can be used as input to the interpreter.
|
|||
If the formatted structures include objects which are not fundamental Python
|
||||
types, the representation may not be loadable. This may be the case if objects
|
||||
such as files, sockets, classes, or instances are included, as well as many
|
||||
other builtin objects which are not representable as Python constants.
|
||||
other built-in objects which are not representable as Python constants.
|
||||
|
||||
The formatted representation keeps objects on a single line if it can, and
|
||||
breaks them onto multiple lines if they don't fit within the allowed width.
|
||||
|
|
|
@ -822,7 +822,7 @@ directly using only a single call on the :class:`Connection` object.
|
|||
Accessing columns by name instead of by index
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
One useful feature of the :mod:`sqlite3` module is the builtin
|
||||
One useful feature of the :mod:`sqlite3` module is the built-in
|
||||
:class:`sqlite3.Row` class designed to be used as a row factory.
|
||||
|
||||
Rows wrapped with this class can be accessed both by index (like tuples) and
|
||||
|
|
|
@ -1595,7 +1595,7 @@ set``. Being an unordered collection, sets do not record element position or
|
|||
order of insertion. Accordingly, sets do not support indexing, slicing, or
|
||||
other sequence-like behavior.
|
||||
|
||||
There are currently two builtin set types, :class:`set` and :class:`frozenset`.
|
||||
There are currently two built-in set types, :class:`set` and :class:`frozenset`.
|
||||
The :class:`set` type is mutable --- the contents can be changed using methods
|
||||
like :meth:`add` and :meth:`remove`. Since it is mutable, it has no hash value
|
||||
and cannot be used as either a dictionary key or as an element of another set.
|
||||
|
|
|
@ -287,7 +287,7 @@ Format Specification Mini-Language
|
|||
|
||||
"Format specifications" are used within replacement fields contained within a
|
||||
format string to define how individual values are presented (see
|
||||
:ref:`formatstrings`.) They can also be passed directly to the builtin
|
||||
:ref:`formatstrings`.) They can also be passed directly to the built-in
|
||||
:func:`format` function. Each formattable type may define how the format
|
||||
specification is to be interpreted.
|
||||
|
||||
|
|
|
@ -738,7 +738,7 @@ always available.
|
|||
|
||||
``'c_call'``
|
||||
A C function is about to be called. This may be an extension function or
|
||||
a builtin. *arg* is the C function object.
|
||||
a built-in. *arg* is the C function object.
|
||||
|
||||
``'c_return'``
|
||||
A C function has returned. *arg* is ``None``.
|
||||
|
|
|
@ -25,4 +25,3 @@ documented beyond this mention. There's little need to document these.
|
|||
|
||||
:mod:`posixpath`
|
||||
--- Implementation of :mod:`os.path` on POSIX.
|
||||
|
||||
|
|
|
@ -62,7 +62,7 @@ instances, functions written in Python (but not in C), instance methods, sets,
|
|||
frozensets, file objects, :term:`generator`\s, type objects, sockets, arrays,
|
||||
deques, and regular expression pattern objects.
|
||||
|
||||
Several builtin types such as :class:`list` and :class:`dict` do not directly
|
||||
Several built-in types such as :class:`list` and :class:`dict` do not directly
|
||||
support weak references but can add support through subclassing::
|
||||
|
||||
class Dict(dict):
|
||||
|
|
|
@ -399,7 +399,7 @@ detached).
|
|||
The object also support comparison semantics, so handle objects will compare
|
||||
true if they both reference the same underlying Windows handle value.
|
||||
|
||||
Handle objects can be converted to an integer (e.g., using the builtin
|
||||
Handle objects can be converted to an integer (e.g., using the built-in
|
||||
:func:`int` function), in which case the underlying Windows handle value is
|
||||
returned. You can also use the :meth:`Detach` method to return the integer
|
||||
handle, and also disconnect the Windows handle from the handle object.
|
||||
|
|
|
@ -87,7 +87,7 @@ between conformable Python objects and XML on the wire.
|
|||
:exc:`ProtocolError` used to signal an error in the HTTP/HTTPS transport layer.
|
||||
Both :exc:`Fault` and :exc:`ProtocolError` derive from a base class called
|
||||
:exc:`Error`. Note that the xmlrpc client module currently does not marshal
|
||||
instances of subclasses of builtin types.
|
||||
instances of subclasses of built-in types.
|
||||
|
||||
When passing strings, characters special to XML such as ``<``, ``>``, and ``&``
|
||||
will be automatically escaped. However, it's the caller's responsibility to
|
||||
|
|
|
@ -10,7 +10,7 @@
|
|||
This module adds the ability to import Python modules (:file:`\*.py`,
|
||||
:file:`\*.py[co]`) and packages from ZIP-format archives. It is usually not
|
||||
needed to use the :mod:`zipimport` module explicitly; it is automatically used
|
||||
by the builtin :keyword:`import` mechanism for ``sys.path`` items that are paths
|
||||
by the built-in :keyword:`import` mechanism for ``sys.path`` items that are paths
|
||||
to ZIP archives.
|
||||
|
||||
Typically, ``sys.path`` is a list of directory names as strings. This module
|
||||
|
|
|
@ -1304,7 +1304,7 @@ access (use of, assignment to, or deletion of ``x.name``) for class instances.
|
|||
.. note::
|
||||
|
||||
This method may still be bypassed when looking up special methods as the
|
||||
result of implicit invocation via language syntax or builtin functions.
|
||||
result of implicit invocation via language syntax or built-in functions.
|
||||
See :ref:`special-lookup`.
|
||||
|
||||
|
||||
|
@ -1696,12 +1696,12 @@ through the container; for mappings, :meth:`__iter__` should be the same as
|
|||
|
||||
.. method:: object.__reversed__(self)
|
||||
|
||||
Called (if present) by the :func:`reversed` builtin to implement
|
||||
Called (if present) by the :func:`reversed` built-in to implement
|
||||
reverse iteration. It should return a new iterator object that iterates
|
||||
over all the objects in the container in reverse order.
|
||||
|
||||
If the :meth:`__reversed__` method is not provided, the :func:`reversed`
|
||||
builtin will fall back to using the sequence protocol (:meth:`__len__` and
|
||||
built-in will fall back to using the sequence protocol (:meth:`__len__` and
|
||||
:meth:`__getitem__`). Objects that support the sequence protocol should
|
||||
only provide :meth:`__reversed__` if they can provide an implementation
|
||||
that is more efficient than the one provided by :func:`reversed`.
|
||||
|
|
|
@ -112,8 +112,8 @@ If the :keyword:`global` statement occurs within a block, all uses of the name
|
|||
specified in the statement refer to the binding of that name in the top-level
|
||||
namespace. Names are resolved in the top-level namespace by searching the
|
||||
global namespace, i.e. the namespace of the module containing the code block,
|
||||
and the builtin namespace, the namespace of the module :mod:`builtins`. The
|
||||
global namespace is searched first. If the name is not found there, the builtin
|
||||
and the builtins namespace, the namespace of the module :mod:`builtins`. The
|
||||
global namespace is searched first. If the name is not found there, the builtins
|
||||
namespace is searched. The global statement must precede all uses of the name.
|
||||
|
||||
.. XXX document "nonlocal" semantics here
|
||||
|
|
|
@ -641,7 +641,7 @@ the call.
|
|||
|
||||
.. note::
|
||||
|
||||
An implementation may provide builtin functions whose positional parameters do
|
||||
An implementation may provide built-in functions whose positional parameters do
|
||||
not have names, even if they are 'named' for the purpose of documentation, and
|
||||
which therefore cannot be supplied by keyword. In CPython, this is the case for
|
||||
functions implemented in C that use :cfunc:`PyArg_ParseTuple` to parse their
|
||||
|
@ -996,7 +996,7 @@ operators *always* consider objects of different types to be unequal, while the
|
|||
``<``, ``>``, ``>=`` and ``<=`` operators raise a :exc:`TypeError` when
|
||||
comparing objects of different types that do not implement these operators for
|
||||
the given pair of types. You can control comparison behavior of objects of
|
||||
non-builtin types by defining rich comparison methods like :meth:`__gt__`,
|
||||
non-built-in types by defining rich comparison methods like :meth:`__gt__`,
|
||||
described in section :ref:`customization`.
|
||||
|
||||
Comparison of objects of the same type depends on the type:
|
||||
|
@ -1037,7 +1037,7 @@ Comparison of objects of the same type depends on the type:
|
|||
which depend on total ordering. For example, :func:`min`, :func:`max`, and
|
||||
:func:`sorted` produce undefined results given a list of sets as inputs.
|
||||
|
||||
* Most other objects of builtin types compare unequal unless they are the same
|
||||
* Most other objects of built-in types compare unequal unless they are the same
|
||||
object; the choice whether one object is considered smaller or larger than
|
||||
another one is made arbitrarily but consistently within one execution of a
|
||||
program.
|
||||
|
|
|
@ -881,7 +881,7 @@ Note that there is nothing special about the statement::
|
|||
That is not a future statement; it's an ordinary import statement with no
|
||||
special semantics or syntax restrictions.
|
||||
|
||||
Code compiled by calls to the builtin functions :func:`exec` and :func:`compile`
|
||||
Code compiled by calls to the built-in functions :func:`exec` and :func:`compile`
|
||||
that occur in a module :mod:`M` containing a future statement will, by default,
|
||||
use the new syntax or semantics associated with the future statement. This can
|
||||
be controlled by optional arguments to :func:`compile` --- see the documentation
|
||||
|
|
|
@ -86,7 +86,7 @@ source.
|
|||
|
||||
.. note::
|
||||
|
||||
This option cannot be used with builtin modules and extension modules
|
||||
This option cannot be used with built-in modules and extension modules
|
||||
written in C, since they do not have Python module files. However, it
|
||||
can still be used for precompiled modules, even if the original source
|
||||
file is not available.
|
||||
|
|
|
@ -1173,7 +1173,7 @@ Some of the more notable changes are:
|
|||
can uncomment them. Gestalt and Internet Config modules are enabled by
|
||||
default.
|
||||
|
||||
* Keyword arguments passed to builtin functions that don't take them now cause a
|
||||
* Keyword arguments passed to built-in functions that don't take them now cause a
|
||||
:exc:`TypeError` exception to be raised, with the message "*function* takes no
|
||||
keyword arguments".
|
||||
|
||||
|
|
|
@ -2823,7 +2823,7 @@ JSON (Javascript Object Notation). JSON is a lightweight interchange format
|
|||
often used in web applications. For more information about JSON, see
|
||||
http://www.json.org.
|
||||
|
||||
:mod:`json` comes with support for decoding and encoding most builtin Python
|
||||
:mod:`json` comes with support for decoding and encoding most built-in Python
|
||||
types. The following example encodes and decodes a dictionary::
|
||||
|
||||
>>> import json
|
||||
|
|
Loading…
Reference in New Issue