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`
|
*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
|
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;
|
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
|
Cache the result in :data:`sys.path_importer_cache`. Return a new reference
|
||||||
to the importer object.
|
to the importer object.
|
||||||
|
|
||||||
|
|
|
@ -372,12 +372,12 @@ the system's :ctype:`wchar_t`.
|
||||||
Built-in Codecs
|
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.
|
these codecs are directly usable via the following functions.
|
||||||
|
|
||||||
Many of the following APIs take two arguments encoding and errors. These
|
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
|
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
|
Setting encoding to *NULL* causes the default encoding to be used
|
||||||
which is ASCII. The file system calls should use
|
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
|
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
|
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
|
The codecs all use a similar interface. Only deviation from the following
|
||||||
generic ones are documented for simplicity.
|
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*.
|
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
|
*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
|
using the Python codec registry. Return *NULL* if an exception was raised by
|
||||||
the codec.
|
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
|
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
|
: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
|
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.
|
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)
|
.. method:: TextFile.open(filename)
|
||||||
|
|
||||||
Open a new file *filename*. This overrides any *file* or *filename* constructor
|
Open a new file *filename*. This overrides any *file* or *filename*
|
||||||
arguments.
|
constructor arguments.
|
||||||
|
|
||||||
|
|
||||||
.. method:: TextFile.close()
|
.. 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.
|
these :class:`PyTypeObject` structures between extension modules.
|
||||||
|
|
||||||
In this example we will create a :class:`Shoddy` type that inherits from the
|
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
|
regular lists, but will have an additional :meth:`increment` method that
|
||||||
increases an internal counter. ::
|
increases an internal counter. ::
|
||||||
|
|
||||||
|
|
|
@ -28,11 +28,11 @@ Glossary
|
||||||
|
|
||||||
abstract base class
|
abstract base class
|
||||||
Abstract Base Classes (abbreviated ABCs) complement :term:`duck-typing` by
|
Abstract Base Classes (abbreviated ABCs) complement :term:`duck-typing` by
|
||||||
providing a way to define interfaces when other techniques like :func:`hasattr`
|
providing a way to define interfaces when other techniques like
|
||||||
would be clumsy. Python comes with many builtin ABCs for data structures
|
:func:`hasattr` would be clumsy. Python comes with many built-in ABCs for
|
||||||
(in the :mod:`collections` module), numbers (in the :mod:`numbers`
|
data structures (in the :mod:`collections` module), numbers (in the
|
||||||
module), and streams (in the :mod:`io` module). You can create your own
|
:mod:`numbers` module), and streams (in the :mod:`io` module). You can
|
||||||
ABC with the :mod:`abc` module.
|
create your own ABC with the :mod:`abc` module.
|
||||||
|
|
||||||
argument
|
argument
|
||||||
A value passed to a function or method, assigned to a named local
|
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
|
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
|
numbers are real multiples of the imaginary unit (the square root of
|
||||||
``-1``), often written ``i`` in mathematics or ``j`` in
|
``-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
|
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
|
``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
|
: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
|
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
|
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
|
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
|
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
|
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``
|
to call :func:`iter` or deal with iterator objects yourself. The ``for``
|
||||||
|
@ -409,7 +409,7 @@ Glossary
|
||||||
|
|
||||||
namespace
|
namespace
|
||||||
The place where a variable is stored. Namespaces are implemented as
|
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
|
as nested namespaces in objects (in methods). Namespaces support
|
||||||
modularity by preventing naming conflicts. For instance, the functions
|
modularity by preventing naming conflicts. For instance, the functions
|
||||||
:func:`builtins.open` and :func:`os.open` are distinguished by their
|
: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
|
More useful functions in :mod:`os.path`: :func:`basename`, :func:`dirname` and
|
||||||
:func:`splitext`.
|
: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
|
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
|
sequence with comparable semantics, for example, yet many people write their own
|
||||||
:func:`max`/:func:`min`. Another highly useful function is
|
: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
|
Handling Exceptions
|
||||||
===================
|
===================
|
||||||
|
|
||||||
*urlopen* raises :exc:`URLError` when it cannot handle a response (though as usual
|
*urlopen* raises :exc:`URLError` when it cannot handle a response (though as
|
||||||
with Python APIs, builtin exceptions such as
|
usual with Python APIs, built-in exceptions such as :exc:`ValueError`,
|
||||||
:exc:`ValueError`, :exc:`TypeError` etc. may also
|
:exc:`TypeError` etc. may also be raised).
|
||||||
be raised).
|
|
||||||
|
|
||||||
:exc:`HTTPError` is the subclass of :exc:`URLError` raised in the specific case of
|
:exc:`HTTPError` is the subclass of :exc:`URLError` raised in the specific case of
|
||||||
HTTP URLs.
|
HTTP URLs.
|
||||||
|
|
|
@ -31,7 +31,7 @@ cur.execute("select ?", ("this is latin1 and would normally create errors" +
|
||||||
row = cur.fetchone()
|
row = cur.fetchone()
|
||||||
assert type(row[0]) == str
|
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
|
# objects, if the data is in ASCII only, and otherwise return unicode objects
|
||||||
con.text_factory = sqlite3.OptimizedUnicode
|
con.text_factory = sqlite3.OptimizedUnicode
|
||||||
cur.execute("select ?", (AUSTRIA,))
|
cur.execute("select ?", (AUSTRIA,))
|
||||||
|
|
|
@ -216,7 +216,7 @@ and off individually. They are described here in more detail.
|
||||||
.. 2to3fixer:: itertools
|
.. 2to3fixer:: itertools
|
||||||
|
|
||||||
Changes usage of :func:`itertools.ifilter`, :func:`itertools.izip`, and
|
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`.
|
:func:`itertools.ifilterfalse` is changed to :func:`itertools.filterfalse`.
|
||||||
|
|
||||||
.. 2to3fixer:: long
|
.. 2to3fixer:: long
|
||||||
|
|
|
@ -52,7 +52,7 @@ Instances of class :class:`_Feature` have two corresponding methods,
|
||||||
:meth:`getOptionalRelease` and :meth:`getMandatoryRelease`.
|
:meth:`getOptionalRelease` and :meth:`getMandatoryRelease`.
|
||||||
|
|
||||||
*CompilerFlag* is the (bitfield) flag that should be passed in the fourth
|
*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`
|
dynamically compiled code. This flag is stored in the :attr:`compiler_flag`
|
||||||
attribute on :class:`_Feature` instances.
|
attribute on :class:`_Feature` instances.
|
||||||
|
|
||||||
|
|
|
@ -16,7 +16,7 @@ Python release; this module helps to find out programmatically what the current
|
||||||
grammar looks like.
|
grammar looks like.
|
||||||
|
|
||||||
An abstract syntax tree can be generated by passing :data:`ast.PyCF_ONLY_AST` as
|
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
|
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
|
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.
|
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[, ...]])
|
.. class:: defaultdict([default_factory[, ...]])
|
||||||
|
|
||||||
Returns a new dictionary-like object. :class:`defaultdict` is a subclass of the
|
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
|
instance variable. The remaining functionality is the same as for the
|
||||||
:class:`dict` class and is not documented here.
|
: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
|
constructor as a dictionary. Additional defaults may be passed into the
|
||||||
:meth:`get` method which will override all others.
|
: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
|
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
|
dictionary type is passed that sorts its keys, the sections will be sorted on
|
||||||
write-back, as will be the keys within each section.
|
write-back, as will be the keys within each section.
|
||||||
|
|
|
@ -606,9 +606,9 @@ the following methods:
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
A *character* means a C character (an ASCII code), rather then a Python
|
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
|
character (a string of length 1). (This note is true whenever the
|
||||||
mentions a character.) The builtin :func:`ord` is handy for conveying strings to
|
documentation mentions a character.) The built-in :func:`ord` is handy for
|
||||||
codes.
|
conveying strings to codes.
|
||||||
|
|
||||||
Paint character *ch* at ``(y, x)`` with attributes *attr*, overwriting any
|
Paint character *ch* at ``(y, x)`` with attributes *attr*, overwriting any
|
||||||
character previously painter at that location. By default, the character
|
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)
|
.. 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
|
*domain*, *localedir*, and *codeset* which are passed to the function
|
||||||
:func:`translation`.
|
: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.'))
|
print(_('This string will be translated.'))
|
||||||
|
|
||||||
For convenience, you want the :func:`_` function to be installed in Python's
|
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.
|
application.
|
||||||
|
|
||||||
|
|
||||||
|
@ -294,7 +294,7 @@ are the methods of :class:`NullTranslations`:
|
||||||
binding it to ``_``.
|
binding it to ``_``.
|
||||||
|
|
||||||
If the *names* parameter is given, it must be a sequence containing the
|
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
|
addition to :func:`_`. Supported names are ``'gettext'`` (bound to
|
||||||
:meth:`self.gettext`), ``'ngettext'`` (bound to :meth:`self.ngettext`),
|
:meth:`self.gettext`), ``'ngettext'`` (bound to :meth:`self.ngettext`),
|
||||||
``'lgettext'`` and ``'lngettext'``.
|
``'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
|
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
|
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.
|
functions.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -12,7 +12,7 @@
|
||||||
.. sectionauthor:: Benjamin Peterson <benjamin@python.org>
|
.. sectionauthor:: Benjamin Peterson <benjamin@python.org>
|
||||||
|
|
||||||
The :mod:`io` module provides the Python interfaces to stream handling. The
|
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
|
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
|
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]])
|
.. method:: apply(func[, args[, kwds]])
|
||||||
|
|
||||||
Call *func* with arguments *args* and keyword arguments *kwds*. It blocks
|
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
|
till the result is ready. Given this blocks, :meth:`apply_async` is better
|
||||||
for performing work in parallel. Additionally, the passed
|
suited for performing work in parallel. Additionally, the passed in
|
||||||
in function is only executed in one of the workers of the pool.
|
function is only executed in one of the workers of the pool.
|
||||||
|
|
||||||
.. method:: apply_async(func[, args[, kwds[, callback]]])
|
.. method:: apply_async(func[, args[, kwds[, callback]]])
|
||||||
|
|
||||||
|
@ -1569,7 +1569,7 @@ with the :class:`Pool` class.
|
||||||
|
|
||||||
.. method:: map(func, iterable[, chunksize])
|
.. 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.
|
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
|
This method chops the iterable into a number of chunks which it submits to
|
||||||
|
|
|
@ -22,7 +22,7 @@ The numeric tower
|
||||||
.. class:: Complex
|
.. class:: Complex
|
||||||
|
|
||||||
Subclasses of this type describe complex numbers and include the operations
|
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`, ``+``,
|
:class:`complex` and :class:`bool`, :attr:`.real`, :attr:`.imag`, ``+``,
|
||||||
``-``, ``*``, ``/``, :func:`abs`, :meth:`conjugate`, ``==``, and ``!=``. All
|
``-``, ``*``, ``/``, :func:`abs`, :meth:`conjugate`, ``==``, and ``!=``. All
|
||||||
except ``-`` and ``!=`` are abstract.
|
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
|
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
|
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
|
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
|
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.
|
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
|
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.
|
: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
|
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
|
order of insertion. Accordingly, sets do not support indexing, slicing, or
|
||||||
other sequence-like behavior.
|
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
|
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
|
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.
|
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 specifications" are used within replacement fields contained within a
|
||||||
format string to define how individual values are presented (see
|
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
|
:func:`format` function. Each formattable type may define how the format
|
||||||
specification is to be interpreted.
|
specification is to be interpreted.
|
||||||
|
|
||||||
|
|
|
@ -738,7 +738,7 @@ always available.
|
||||||
|
|
||||||
``'c_call'``
|
``'c_call'``
|
||||||
A C function is about to be called. This may be an extension function or
|
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'``
|
``'c_return'``
|
||||||
A C function has returned. *arg* is ``None``.
|
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`
|
:mod:`posixpath`
|
||||||
--- Implementation of :mod:`os.path` on POSIX.
|
--- 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,
|
frozensets, file objects, :term:`generator`\s, type objects, sockets, arrays,
|
||||||
deques, and regular expression pattern objects.
|
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::
|
support weak references but can add support through subclassing::
|
||||||
|
|
||||||
class Dict(dict):
|
class Dict(dict):
|
||||||
|
|
|
@ -399,7 +399,7 @@ detached).
|
||||||
The object also support comparison semantics, so handle objects will compare
|
The object also support comparison semantics, so handle objects will compare
|
||||||
true if they both reference the same underlying Windows handle value.
|
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
|
: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
|
returned. You can also use the :meth:`Detach` method to return the integer
|
||||||
handle, and also disconnect the Windows handle from the handle object.
|
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.
|
: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
|
Both :exc:`Fault` and :exc:`ProtocolError` derive from a base class called
|
||||||
:exc:`Error`. Note that the xmlrpc client module currently does not marshal
|
: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 ``&``
|
When passing strings, characters special to XML such as ``<``, ``>``, and ``&``
|
||||||
will be automatically escaped. However, it's the caller's responsibility to
|
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`,
|
This module adds the ability to import Python modules (:file:`\*.py`,
|
||||||
:file:`\*.py[co]`) and packages from ZIP-format archives. It is usually not
|
: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
|
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.
|
to ZIP archives.
|
||||||
|
|
||||||
Typically, ``sys.path`` is a list of directory names as strings. This module
|
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::
|
.. note::
|
||||||
|
|
||||||
This method may still be bypassed when looking up special methods as the
|
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`.
|
See :ref:`special-lookup`.
|
||||||
|
|
||||||
|
|
||||||
|
@ -1696,12 +1696,12 @@ through the container; for mappings, :meth:`__iter__` should be the same as
|
||||||
|
|
||||||
.. method:: object.__reversed__(self)
|
.. 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
|
reverse iteration. It should return a new iterator object that iterates
|
||||||
over all the objects in the container in reverse order.
|
over all the objects in the container in reverse order.
|
||||||
|
|
||||||
If the :meth:`__reversed__` method is not provided, the :func:`reversed`
|
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
|
:meth:`__getitem__`). Objects that support the sequence protocol should
|
||||||
only provide :meth:`__reversed__` if they can provide an implementation
|
only provide :meth:`__reversed__` if they can provide an implementation
|
||||||
that is more efficient than the one provided by :func:`reversed`.
|
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
|
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
|
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,
|
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
|
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 builtin
|
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.
|
namespace is searched. The global statement must precede all uses of the name.
|
||||||
|
|
||||||
.. XXX document "nonlocal" semantics here
|
.. XXX document "nonlocal" semantics here
|
||||||
|
|
|
@ -641,7 +641,7 @@ the call.
|
||||||
|
|
||||||
.. note::
|
.. 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
|
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
|
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
|
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
|
``<``, ``>``, ``>=`` and ``<=`` operators raise a :exc:`TypeError` when
|
||||||
comparing objects of different types that do not implement these operators for
|
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
|
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`.
|
described in section :ref:`customization`.
|
||||||
|
|
||||||
Comparison of objects of the same type depends on the type:
|
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
|
which depend on total ordering. For example, :func:`min`, :func:`max`, and
|
||||||
:func:`sorted` produce undefined results given a list of sets as inputs.
|
: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
|
object; the choice whether one object is considered smaller or larger than
|
||||||
another one is made arbitrarily but consistently within one execution of a
|
another one is made arbitrarily but consistently within one execution of a
|
||||||
program.
|
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
|
That is not a future statement; it's an ordinary import statement with no
|
||||||
special semantics or syntax restrictions.
|
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,
|
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
|
use the new syntax or semantics associated with the future statement. This can
|
||||||
be controlled by optional arguments to :func:`compile` --- see the documentation
|
be controlled by optional arguments to :func:`compile` --- see the documentation
|
||||||
|
|
|
@ -86,7 +86,7 @@ source.
|
||||||
|
|
||||||
.. note::
|
.. 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
|
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
|
can still be used for precompiled modules, even if the original source
|
||||||
file is not available.
|
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
|
can uncomment them. Gestalt and Internet Config modules are enabled by
|
||||||
default.
|
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
|
:exc:`TypeError` exception to be raised, with the message "*function* takes no
|
||||||
keyword arguments".
|
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
|
often used in web applications. For more information about JSON, see
|
||||||
http://www.json.org.
|
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::
|
types. The following example encodes and decodes a dictionary::
|
||||||
|
|
||||||
>>> import json
|
>>> import json
|
||||||
|
|
Loading…
Reference in New Issue