mirror of https://github.com/python/cpython
builtin -> built-in.
This commit is contained in:
parent
9fa61bb37d
commit
d7d4fd7336
|
@ -31,7 +31,7 @@ interface can be written to a file. There are a number of format codes to
|
||||||
returning data from the target object.
|
returning data from the target object.
|
||||||
|
|
||||||
Starting from version 1.6, Python has been providing Python-level buffer
|
Starting from version 1.6, Python has been providing Python-level buffer
|
||||||
objects and a C-level buffer API so that any builtin or used-defined type can
|
objects and a C-level buffer API so that any built-in or used-defined type can
|
||||||
expose its characteristics. Both, however, have been deprecated because of
|
expose its characteristics. Both, however, have been deprecated because of
|
||||||
various shortcomings, and have been officially removed in Python 3.0 in favour
|
various shortcomings, and have been officially removed in Python 3.0 in favour
|
||||||
of a new C-level buffer API and a new Python-level object named
|
of a new C-level buffer API and a new Python-level object named
|
||||||
|
|
|
@ -167,7 +167,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.
|
||||||
|
|
||||||
|
|
|
@ -292,12 +292,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 which is
|
Setting encoding to *NULL* causes the default encoding to be used which is
|
||||||
ASCII. The file system calls should use :cdata:`Py_FileSystemDefaultEncoding`
|
ASCII. The file system calls should use :cdata:`Py_FileSystemDefaultEncoding`
|
||||||
|
@ -307,7 +307,7 @@ at run-time (such as when the application invokes setlocale).
|
||||||
|
|
||||||
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.
|
||||||
|
@ -321,7 +321,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()
|
||||||
|
|
|
@ -819,7 +819,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
|
||||||
|
@ -79,7 +79,7 @@ Glossary
|
||||||
in ``3+4.5``, each argument is of a different type (one int, one float),
|
in ``3+4.5``, each argument is of a different type (one int, one float),
|
||||||
and both must be converted to the same type before they can be added or it
|
and both must be converted to the same type before they can be added or it
|
||||||
will raise a ``TypeError``. Coercion between two operands can be
|
will raise a ``TypeError``. Coercion between two operands can be
|
||||||
performed with the ``coerce`` builtin function; thus, ``3+4.5`` is
|
performed with the ``coerce`` built-in function; thus, ``3+4.5`` is
|
||||||
equivalent to calling ``operator.add(*coerce(3, 4.5))`` and results in
|
equivalent to calling ``operator.add(*coerce(3, 4.5))`` and results in
|
||||||
``operator.add(3.0, 4.5)``. Without coercion, all arguments of even
|
``operator.add(3.0, 4.5)``. Without coercion, all arguments of even
|
||||||
compatible types would have to be normalized to the same value by the
|
compatible types would have to be normalized to the same value by the
|
||||||
|
@ -90,7 +90,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
|
||||||
|
@ -322,7 +322,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``
|
||||||
|
@ -424,7 +424,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:`__builtin__.open` and :func:`os.open` are distinguished by their
|
:func:`__builtin__.open` and :func:`os.open` are distinguished by their
|
||||||
|
|
|
@ -261,7 +261,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:`reduce`. A
|
:func:`max`/:func:`min`. Another highly useful function is :func:`reduce`. A
|
||||||
|
|
|
@ -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]) == unicode
|
assert type(row[0]) == unicode
|
||||||
|
|
||||||
# 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,))
|
||||||
|
|
|
@ -209,7 +209,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.
|
||||||
|
|
||||||
|
|
|
@ -408,7 +408,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.
|
||||||
|
|
|
@ -22,7 +22,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.
|
||||||
|
|
|
@ -509,7 +509,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.
|
||||||
|
|
||||||
|
|
|
@ -21,11 +21,11 @@ Python. It uses the built-in parser and standard :mod:`parser` module to
|
||||||
generated a concrete syntax tree. This tree is used to generate an abstract
|
generated a concrete syntax tree. This tree is used to generate an abstract
|
||||||
syntax tree (AST) and then Python bytecode.
|
syntax tree (AST) and then Python bytecode.
|
||||||
|
|
||||||
The full functionality of the package duplicates the builtin compiler provided
|
The full functionality of the package duplicates the built-in compiler provided
|
||||||
with the Python interpreter. It is intended to match its behavior almost
|
with the Python interpreter. It is intended to match its behavior almost
|
||||||
exactly. Why implement another compiler that does the same thing? The package
|
exactly. Why implement another compiler that does the same thing? The package
|
||||||
is useful for a variety of purposes. It can be modified more easily than the
|
is useful for a variety of purposes. It can be modified more easily than the
|
||||||
builtin compiler. The AST it generates is useful for analyzing Python source
|
built-in compiler. The AST it generates is useful for analyzing Python source
|
||||||
code.
|
code.
|
||||||
|
|
||||||
This chapter explains how the various components of the :mod:`compiler` package
|
This chapter explains how the various components of the :mod:`compiler` package
|
||||||
|
@ -118,7 +118,7 @@ for a construct, there are often several levels of nested nodes that are
|
||||||
introduced by Python's precedence rules.
|
introduced by Python's precedence rules.
|
||||||
|
|
||||||
The abstract syntax tree is created by the :mod:`compiler.transformer` module.
|
The abstract syntax tree is created by the :mod:`compiler.transformer` module.
|
||||||
The transformer relies on the builtin Python parser to generate a concrete
|
The transformer relies on the built-in Python parser to generate a concrete
|
||||||
syntax tree. It generates an abstract syntax tree from the concrete tree.
|
syntax tree. It generates an abstract syntax tree from the concrete tree.
|
||||||
|
|
||||||
.. index::
|
.. index::
|
||||||
|
|
|
@ -56,7 +56,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.
|
||||||
|
|
|
@ -609,9 +609,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
|
||||||
|
|
|
@ -847,7 +847,7 @@ available. They are listed here in alphabetical order.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
This function is not normally available as a builtin since the name
|
This function is not normally available as a built-in since the name
|
||||||
``print`` is recognized as the :keyword:`print` statement. To disable the
|
``print`` is recognized as the :keyword:`print` statement. To disable the
|
||||||
statement and use the :func:`print` function, use this future statement at
|
statement and use the :func:`print` function, use this future statement at
|
||||||
the top of your module::
|
the top of your module::
|
||||||
|
|
|
@ -1,14 +1,14 @@
|
||||||
:mod:`future_builtins` --- Python 3 builtins
|
:mod:`future_builtins` --- Python 3 built-ins
|
||||||
============================================
|
=============================================
|
||||||
|
|
||||||
.. module:: future_builtins
|
.. module:: future_builtins
|
||||||
.. sectionauthor:: Georg Brandl
|
.. sectionauthor:: Georg Brandl
|
||||||
.. versionadded:: 2.6
|
.. versionadded:: 2.6
|
||||||
|
|
||||||
This module provides functions that exist in 2.x, but have different behavior in
|
This module provides functions that exist in 2.x, but have different behavior in
|
||||||
Python 3, so they cannot be put into the 2.x builtin namespace.
|
Python 3, so they cannot be put into the 2.x builtins namespace.
|
||||||
|
|
||||||
Instead, if you want to write code compatible with Python 3 builtins, import
|
Instead, if you want to write code compatible with Python 3 built-ins, import
|
||||||
them from this module, like this::
|
them from this module, like this::
|
||||||
|
|
||||||
from future_builtins import map, filter
|
from future_builtins import map, filter
|
||||||
|
@ -16,17 +16,17 @@ them from this module, like this::
|
||||||
... code using Python 3-style map and filter ...
|
... code using Python 3-style map and filter ...
|
||||||
|
|
||||||
The :term:`2to3` tool that ports Python 2 code to Python 3 will recognize
|
The :term:`2to3` tool that ports Python 2 code to Python 3 will recognize
|
||||||
this usage and leave the new builtins alone.
|
this usage and leave the new built-ins alone.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
The Python 3 :func:`print` function is already in the builtins, but cannot be
|
The Python 3 :func:`print` function is already in the built-ins, but cannot be
|
||||||
accessed from Python 2 code unless you use the appropriate future statement::
|
accessed from Python 2 code unless you use the appropriate future statement::
|
||||||
|
|
||||||
from __future__ import print_function
|
from __future__ import print_function
|
||||||
|
|
||||||
|
|
||||||
Available builtins are:
|
Available built-ins are:
|
||||||
|
|
||||||
.. function:: ascii(object)
|
.. function:: ascii(object)
|
||||||
|
|
||||||
|
@ -42,7 +42,7 @@ Available builtins are:
|
||||||
|
|
||||||
.. function:: hex(object)
|
.. function:: hex(object)
|
||||||
|
|
||||||
Works like the builtin :func:`hex`, but instead of :meth:`__hex__` it will
|
Works like the built-in :func:`hex`, but instead of :meth:`__hex__` it will
|
||||||
use the :meth:`__index__` method on its argument to get an integer that is
|
use the :meth:`__index__` method on its argument to get an integer that is
|
||||||
then converted to hexadecimal.
|
then converted to hexadecimal.
|
||||||
|
|
||||||
|
@ -52,7 +52,7 @@ Available builtins are:
|
||||||
|
|
||||||
.. function:: oct(object)
|
.. function:: oct(object)
|
||||||
|
|
||||||
Works like the builtin :func:`oct`, but instead of :meth:`__oct__` it will
|
Works like the built-in :func:`oct`, but instead of :meth:`__oct__` it will
|
||||||
use the :meth:`__index__` method on its argument to get an integer that is
|
use the :meth:`__index__` method on its argument to get an integer that is
|
||||||
then converted to octal.
|
then converted to octal.
|
||||||
|
|
||||||
|
|
|
@ -48,7 +48,7 @@ The :mod:`gc` module provides the following functions:
|
||||||
The optional *generation* argument was added.
|
The optional *generation* argument was added.
|
||||||
|
|
||||||
.. versionchanged:: 2.6
|
.. versionchanged:: 2.6
|
||||||
The free lists maintained for a number of builtin types are cleared
|
The free lists maintained for a number of built-in types are cleared
|
||||||
whenever a full collection or collection of the highest generation (2)
|
whenever a full collection or collection of the highest generation (2)
|
||||||
is run. Not all items in some free lists may be freed due to the
|
is run. Not all items in some free lists may be freed due to the
|
||||||
particular implementation, in particular :class:`int` and :class:`float`.
|
particular implementation, in particular :class:`int` and :class:`float`.
|
||||||
|
|
|
@ -205,7 +205,7 @@ the built-in namespace as the function :func:`_`.
|
||||||
|
|
||||||
.. function:: install(domain[, localedir[, unicode [, codeset[, names]]]])
|
.. function:: install(domain[, localedir[, unicode [, codeset[, names]]]])
|
||||||
|
|
||||||
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`. The *unicode* flag is passed to the resulting translation
|
:func:`translation`. The *unicode* flag is passed to the resulting translation
|
||||||
object's :meth:`install` method.
|
object's :meth:`install` method.
|
||||||
|
@ -220,7 +220,7 @@ the built-in namespace as the function :func:`_`.
|
||||||
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.
|
||||||
|
|
||||||
.. versionchanged:: 2.4
|
.. versionchanged:: 2.4
|
||||||
|
@ -347,7 +347,7 @@ are the methods of :class:`NullTranslations`:
|
||||||
it binds :meth:`self.ugettext` instead. By default, *unicode* is false.
|
it binds :meth:`self.ugettext` instead. By default, *unicode* is false.
|
||||||
|
|
||||||
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` or :meth:`self.ugettext` according to the *unicode*
|
:meth:`self.gettext` or :meth:`self.ugettext` according to the *unicode*
|
||||||
flag), ``'ngettext'`` (bound to :meth:`self.ngettext` or
|
flag), ``'ngettext'`` (bound to :meth:`self.ngettext` or
|
||||||
|
|
|
@ -147,7 +147,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.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -79,7 +79,7 @@ approach to custom :keyword:`import` functions.
|
||||||
|
|
||||||
.. class:: BuiltinImporter()
|
.. class:: BuiltinImporter()
|
||||||
|
|
||||||
Emulate the import mechanism for builtin and frozen modules. This is a
|
Emulate the import mechanism for built-in and frozen modules. This is a
|
||||||
sub-class of the :class:`Importer` class.
|
sub-class of the :class:`Importer` class.
|
||||||
|
|
||||||
.. method:: BuiltinImporter.get_code(parent, modname, fqname)
|
.. method:: BuiltinImporter.get_code(parent, modname, fqname)
|
||||||
|
|
|
@ -10,7 +10,7 @@
|
||||||
.. versionadded:: 2.6
|
.. versionadded:: 2.6
|
||||||
|
|
||||||
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
|
||||||
|
|
|
@ -1555,8 +1555,8 @@ with the :class:`Pool` class.
|
||||||
|
|
||||||
.. method:: apply(func[, args[, kwds]])
|
.. method:: apply(func[, args[, kwds]])
|
||||||
|
|
||||||
Equivalent of the :func:`apply` builtin function. It blocks till the
|
Equivalent of the :func:`apply` built-in function. It blocks till the
|
||||||
result is ready. Given this blocks - :meth:`apply_async` is better suited
|
result is ready. Given this blocks, :meth:`apply_async` is better suited
|
||||||
for performing work in parallel. Additionally, the passed
|
for performing work in parallel. Additionally, the passed
|
||||||
in function is only executed in one of the workers of the pool.
|
in function is only executed in one of the workers of the pool.
|
||||||
|
|
||||||
|
@ -1571,7 +1571,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
|
||||||
|
|
|
@ -24,7 +24,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.
|
||||||
|
|
|
@ -184,7 +184,7 @@ any iterable as an argument.
|
||||||
Also note, the module also includes a :meth:`union_update` method which is an
|
Also note, the module also includes a :meth:`union_update` method which is an
|
||||||
alias for :meth:`update`. The method is included for backwards compatibility.
|
alias for :meth:`update`. The method is included for backwards compatibility.
|
||||||
Programmers should prefer the :meth:`update` method because it is supported by
|
Programmers should prefer the :meth:`update` method because it is supported by
|
||||||
the builtin :class:`set()` and :class:`frozenset()` types.
|
the built-in :class:`set()` and :class:`frozenset()` types.
|
||||||
|
|
||||||
|
|
||||||
.. _set-example:
|
.. _set-example:
|
||||||
|
|
|
@ -840,7 +840,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
|
||||||
|
|
|
@ -277,7 +277,7 @@ numbers of mixed type use the same rule. [#]_ The constructors :func:`int`,
|
||||||
:func:`long`, :func:`float`, and :func:`complex` can be used to produce numbers
|
:func:`long`, :func:`float`, and :func:`complex` can be used to produce numbers
|
||||||
of a specific type.
|
of a specific type.
|
||||||
|
|
||||||
All builtin numeric types support the following operations. See
|
All built-in numeric types support the following operations. See
|
||||||
:ref:`power` and later sections for the operators' priorities.
|
:ref:`power` and later sections for the operators' priorities.
|
||||||
|
|
||||||
+--------------------+---------------------------------+--------+
|
+--------------------+---------------------------------+--------+
|
||||||
|
@ -675,7 +675,7 @@ must have the enclosing parentheses, such as ``a, b, c`` or ``()``. A
|
||||||
single item tuple must have a trailing comma, such as ``(d,)``.
|
single item tuple must have a trailing comma, such as ``(d,)``.
|
||||||
|
|
||||||
Buffer objects are not directly supported by Python syntax, but can be created
|
Buffer objects are not directly supported by Python syntax, but can be created
|
||||||
by calling the builtin function :func:`buffer`. They don't support
|
by calling the built-in function :func:`buffer`. They don't support
|
||||||
concatenation or repetition.
|
concatenation or repetition.
|
||||||
|
|
||||||
Objects of type xrange are similar to buffers in that there is no specific syntax to
|
Objects of type xrange are similar to buffers in that there is no specific syntax to
|
||||||
|
@ -1632,7 +1632,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.
|
||||||
|
|
|
@ -312,7 +312,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.
|
||||||
|
|
||||||
|
|
|
@ -816,7 +816,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``.
|
||||||
|
|
|
@ -113,7 +113,7 @@ BuildApplication to combine all plugin modules to a single executable.
|
||||||
:deprecated:
|
:deprecated:
|
||||||
|
|
||||||
|
|
||||||
Importing :mod:`icopen` will replace the builtin :meth:`open` with a version
|
Importing :mod:`icopen` will replace the built-in :meth:`open` with a version
|
||||||
that uses Internet Config to set file type and creator for new files.
|
that uses Internet Config to set file type and creator for new files.
|
||||||
|
|
||||||
.. deprecated:: 2.6
|
.. deprecated:: 2.6
|
||||||
|
|
|
@ -65,7 +65,7 @@ and regular expression pattern objects.
|
||||||
.. versionchanged:: 2.4
|
.. versionchanged:: 2.4
|
||||||
Added support for files, sockets, arrays, and patterns.
|
Added support for files, sockets, arrays, and patterns.
|
||||||
|
|
||||||
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):
|
||||||
|
|
|
@ -94,7 +94,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 even though starting with Python 2.2 you can subclass
|
:exc:`Error`. Note that even though starting with Python 2.2 you can subclass
|
||||||
builtin types, the xmlrpclib module currently does not marshal instances of such
|
built-in types, the xmlrpclib module currently does not marshal instances of such
|
||||||
subclasses.
|
subclasses.
|
||||||
|
|
||||||
When passing strings, characters special to XML such as ``<``, ``>``, and ``&``
|
When passing strings, characters special to XML such as ``<``, ``>``, and ``&``
|
||||||
|
|
|
@ -12,7 +12,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
|
||||||
|
|
|
@ -1437,7 +1437,7 @@ Basic customization
|
||||||
|
|
||||||
.. index:: builtin: unicode
|
.. index:: builtin: unicode
|
||||||
|
|
||||||
Called to implement :func:`unicode` builtin; should return a Unicode object.
|
Called to implement :func:`unicode` built-in; should return a Unicode object.
|
||||||
When this method is not defined, string conversion is attempted, and the result
|
When this method is not defined, string conversion is attempted, and the result
|
||||||
of string conversion is converted to Unicode using the system default encoding.
|
of string conversion is converted to Unicode using the system default encoding.
|
||||||
|
|
||||||
|
@ -1516,7 +1516,7 @@ The following methods only apply to new-style classes.
|
||||||
.. 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:`new-style-special-lookup`.
|
See :ref:`new-style-special-lookup`.
|
||||||
|
|
||||||
|
|
||||||
|
@ -1865,12 +1865,12 @@ sequences, it should iterate through the values.
|
||||||
|
|
||||||
.. 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,9 +112,9 @@ determined by scanning the entire text of the block for name binding operations.
|
||||||
If the global statement occurs within a block, all uses of the name specified in
|
If the 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.
|
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,
|
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
|
i.e. the namespace of the module containing the code block, and the builtins
|
||||||
namespace, the namespace of the module :mod:`__builtin__`. The global namespace
|
namespace, the namespace of the module :mod:`__builtin__`. The global namespace
|
||||||
is searched first. If the name is not found there, the builtin namespace is
|
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.
|
searched. The global statement must precede all uses of the name.
|
||||||
|
|
||||||
.. index:: pair: restricted; execution
|
.. index:: pair: restricted; execution
|
||||||
|
|
|
@ -665,7 +665,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
|
||||||
|
@ -1032,7 +1032,7 @@ The operators ``<``, ``>``, ``==``, ``>=``, ``<=``, and ``!=`` compare the
|
||||||
values of two objects. The objects need not have the same type. If both are
|
values of two objects. The objects need not have the same type. If both are
|
||||||
numbers, they are converted to a common type. Otherwise, objects of different
|
numbers, they are converted to a common type. Otherwise, objects of different
|
||||||
types *always* compare unequal, and are ordered consistently but arbitrarily.
|
types *always* compare unequal, and are ordered consistently but arbitrarily.
|
||||||
You can control comparison behavior of objects of non-builtin types by defining
|
You can control comparison behavior of objects of non-built-in types by defining
|
||||||
a ``__cmp__`` method or rich comparison methods like ``__gt__``, described in
|
a ``__cmp__`` method or rich comparison methods like ``__gt__``, described in
|
||||||
section :ref:`specialnames`.
|
section :ref:`specialnames`.
|
||||||
|
|
||||||
|
@ -1063,7 +1063,7 @@ Comparison of objects of the same type depends on the type:
|
||||||
lists compare equal. [#]_ Outcomes other than equality are resolved
|
lists compare equal. [#]_ Outcomes other than equality are resolved
|
||||||
consistently, but are not otherwise defined. [#]_
|
consistently, but are not otherwise defined. [#]_
|
||||||
|
|
||||||
* 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.
|
||||||
|
|
|
@ -891,7 +891,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 an :keyword:`exec` statement or calls to the builtin functions
|
Code compiled by an :keyword:`exec` statement or calls to the built-in functions
|
||||||
:func:`compile` and :func:`execfile` that occur in a module :mod:`M` containing
|
:func:`compile` and :func:`execfile` that occur in a module :mod:`M` containing
|
||||||
a future statement will, by default, use the new syntax or semantics associated
|
a future statement will, by default, use the new syntax or semantics associated
|
||||||
with the future statement. This can, starting with Python 2.2 be controlled by
|
with the future statement. This can, starting with Python 2.2 be controlled by
|
||||||
|
|
|
@ -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".
|
||||||
|
|
||||||
|
|
|
@ -2819,7 +2819,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