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.
|
||||
|
||||
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
|
||||
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
|
||||
|
|
|
@ -167,7 +167,7 @@ Importing Modules
|
|||
*path*, possibly by fetching it from the :data:`sys.path_importer_cache`
|
||||
dict. If it wasn't yet cached, traverse :data:`sys.path_hooks` until a hook
|
||||
is found that can handle the path item. Return ``None`` if no hook could;
|
||||
this tells our caller it should fall back to the builtin import mechanism.
|
||||
this tells our caller it should fall back to the built-in import mechanism.
|
||||
Cache the result in :data:`sys.path_importer_cache`. Return a new reference
|
||||
to the importer object.
|
||||
|
||||
|
|
|
@ -292,12 +292,12 @@ the system's :ctype:`wchar_t`.
|
|||
Built-in Codecs
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
Python provides a set of builtin codecs which are written in C for speed. All of
|
||||
Python provides a set of built-in codecs which are written in C for speed. All of
|
||||
these codecs are directly usable via the following functions.
|
||||
|
||||
Many of the following APIs take two arguments encoding and errors. These
|
||||
parameters encoding and errors have the same semantics as the ones of the
|
||||
builtin unicode() Unicode object constructor.
|
||||
built-in :func:`unicode` Unicode object constructor.
|
||||
|
||||
Setting encoding to *NULL* causes the default encoding to be used which is
|
||||
ASCII. The file system calls should use :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
|
||||
the default handling defined for the codec. Default error handling for all
|
||||
builtin codecs is "strict" (:exc:`ValueError` is raised).
|
||||
built-in codecs is "strict" (:exc:`ValueError` is raised).
|
||||
|
||||
The codecs all use a similar interface. Only deviation from the following
|
||||
generic ones are documented for simplicity.
|
||||
|
@ -321,7 +321,7 @@ These are the generic codec APIs:
|
|||
|
||||
Create a Unicode object by decoding *size* bytes of the encoded string *s*.
|
||||
*encoding* and *errors* have the same meaning as the parameters of the same name
|
||||
in the :func:`unicode` builtin function. The codec to be used is looked up
|
||||
in the :func:`unicode` built-in function. The codec to be used is looked up
|
||||
using the Python codec registry. Return *NULL* if an exception was raised by
|
||||
the codec.
|
||||
|
||||
|
|
|
@ -1601,7 +1601,7 @@ lines, and joining lines with backslashes.
|
|||
+------------------+--------------------------------+---------+
|
||||
|
||||
Note that since *rstrip_ws* can strip the trailing newline, the semantics of
|
||||
:meth:`readline` must differ from those of the builtin file object's
|
||||
:meth:`readline` must differ from those of the built-in file object's
|
||||
:meth:`readline` method! In particular, :meth:`readline` returns ``None`` for
|
||||
end-of-file: an empty string might just be a blank line (or an all-whitespace
|
||||
line), if *rstrip_ws* is true but *skip_blanks* is not.
|
||||
|
@ -1609,8 +1609,8 @@ lines, and joining lines with backslashes.
|
|||
|
||||
.. method:: TextFile.open(filename)
|
||||
|
||||
Open a new file *filename*. This overrides any *file* or *filename* constructor
|
||||
arguments.
|
||||
Open a new file *filename*. This overrides any *file* or *filename*
|
||||
constructor arguments.
|
||||
|
||||
|
||||
.. method:: TextFile.close()
|
||||
|
|
|
@ -819,7 +819,7 @@ easily use the :class:`PyTypeObject` it needs. It can be difficult to share
|
|||
these :class:`PyTypeObject` structures between extension modules.
|
||||
|
||||
In this example we will create a :class:`Shoddy` type that inherits from the
|
||||
builtin :class:`list` type. The new type will be completely compatible with
|
||||
built-in :class:`list` type. The new type will be completely compatible with
|
||||
regular lists, but will have an additional :meth:`increment` method that
|
||||
increases an internal counter. ::
|
||||
|
||||
|
|
|
@ -28,11 +28,11 @@ Glossary
|
|||
|
||||
abstract base class
|
||||
Abstract Base Classes (abbreviated ABCs) complement :term:`duck-typing` by
|
||||
providing a way to define interfaces when other techniques like :func:`hasattr`
|
||||
would be clumsy. Python comes with many builtin ABCs for data structures
|
||||
(in the :mod:`collections` module), numbers (in the :mod:`numbers`
|
||||
module), and streams (in the :mod:`io` module). You can create your own
|
||||
ABC with the :mod:`abc` module.
|
||||
providing a way to define interfaces when other techniques like
|
||||
:func:`hasattr` would be clumsy. Python comes with many built-in ABCs for
|
||||
data structures (in the :mod:`collections` module), numbers (in the
|
||||
:mod:`numbers` module), and streams (in the :mod:`io` module). You can
|
||||
create your own ABC with the :mod:`abc` module.
|
||||
|
||||
argument
|
||||
A value passed to a function or method, assigned to a named local
|
||||
|
@ -79,7 +79,7 @@ Glossary
|
|||
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
|
||||
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
|
||||
``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
|
||||
|
@ -90,7 +90,7 @@ Glossary
|
|||
expressed as a sum of a real part and an imaginary part. Imaginary
|
||||
numbers are real multiples of the imaginary unit (the square root of
|
||||
``-1``), often written ``i`` in mathematics or ``j`` in
|
||||
engineering. Python has builtin support for complex numbers, which are
|
||||
engineering. Python has built-in support for complex numbers, which are
|
||||
written with this latter notation; the imaginary part is written with a
|
||||
``j`` suffix, e.g., ``3+1j``. To get access to complex equivalents of the
|
||||
:mod:`math` module, use :mod:`cmath`. Use of complex numbers is a fairly
|
||||
|
@ -322,7 +322,7 @@ Glossary
|
|||
define with an :meth:`__iter__` or :meth:`__getitem__` method. Iterables
|
||||
can be used in a :keyword:`for` loop and in many other places where a
|
||||
sequence is needed (:func:`zip`, :func:`map`, ...). When an iterable
|
||||
object is passed as an argument to the builtin function :func:`iter`, it
|
||||
object is passed as an argument to the built-in function :func:`iter`, it
|
||||
returns an iterator for the object. This iterator is good for one pass
|
||||
over the set of values. When using iterables, it is usually not necessary
|
||||
to call :func:`iter` or deal with iterator objects yourself. The ``for``
|
||||
|
@ -424,7 +424,7 @@ Glossary
|
|||
|
||||
namespace
|
||||
The place where a variable is stored. Namespaces are implemented as
|
||||
dictionaries. There are the local, global and builtin namespaces as well
|
||||
dictionaries. There are the local, global and built-in namespaces as well
|
||||
as nested namespaces in objects (in methods). Namespaces support
|
||||
modularity by preventing naming conflicts. For instance, the functions
|
||||
:func:`__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
|
||||
:func:`splitext`.
|
||||
|
||||
There are also many useful builtin functions people seem not to be aware of for
|
||||
There are also many useful built-in functions people seem not to be aware of for
|
||||
some reason: :func:`min` and :func:`max` can find the minimum/maximum of any
|
||||
sequence with comparable semantics, for example, yet many people write their own
|
||||
:func:`max`/:func:`min`. Another highly useful function is :func:`reduce`. A
|
||||
|
|
|
@ -182,10 +182,9 @@ which comes after we have a look at what happens when things go wrong.
|
|||
Handling Exceptions
|
||||
===================
|
||||
|
||||
*urlopen* raises :exc:`URLError` when it cannot handle a response (though as usual
|
||||
with Python APIs, builtin exceptions such as
|
||||
:exc:`ValueError`, :exc:`TypeError` etc. may also
|
||||
be raised).
|
||||
*urlopen* raises :exc:`URLError` when it cannot handle a response (though as
|
||||
usual with Python APIs, built-in exceptions such as :exc:`ValueError`,
|
||||
:exc:`TypeError` etc. may also be raised).
|
||||
|
||||
:exc:`HTTPError` is the subclass of :exc:`URLError` raised in the specific case of
|
||||
HTTP URLs.
|
||||
|
|
|
@ -31,7 +31,7 @@ cur.execute("select ?", ("this is latin1 and would normally create errors" +
|
|||
row = cur.fetchone()
|
||||
assert type(row[0]) == 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
|
||||
con.text_factory = sqlite3.OptimizedUnicode
|
||||
cur.execute("select ?", (AUSTRIA,))
|
||||
|
|
|
@ -209,7 +209,7 @@ and off individually. They are described here in more detail.
|
|||
.. 2to3fixer:: itertools
|
||||
|
||||
Changes usage of :func:`itertools.ifilter`, :func:`itertools.izip`, and
|
||||
:func:`itertools.imap` to their builtin equivalents.
|
||||
:func:`itertools.imap` to their built-in equivalents.
|
||||
:func:`itertools.ifilterfalse` is changed to :func:`itertools.filterfalse`.
|
||||
|
||||
.. 2to3fixer:: long
|
||||
|
|
|
@ -52,7 +52,7 @@ Instances of class :class:`_Feature` have two corresponding methods,
|
|||
:meth:`getOptionalRelease` and :meth:`getMandatoryRelease`.
|
||||
|
||||
*CompilerFlag* is the (bitfield) flag that should be passed in the fourth
|
||||
argument to the builtin function :func:`compile` to enable the feature in
|
||||
argument to the built-in function :func:`compile` to enable the feature in
|
||||
dynamically compiled code. This flag is stored in the :attr:`compiler_flag`
|
||||
attribute on :class:`_Feature` instances.
|
||||
|
||||
|
|
|
@ -408,7 +408,7 @@ detached).
|
|||
The object also support comparison semantics, so handle objects will compare
|
||||
true if they both reference the same underlying Windows handle value.
|
||||
|
||||
Handle objects can be converted to an integer (e.g., using the builtin
|
||||
Handle objects can be converted to an integer (e.g., using the built-in
|
||||
:func:`int` function), in which case the underlying Windows handle value is
|
||||
returned. You can also use the :meth:`Detach` method to return the integer
|
||||
handle, and also disconnect the Windows handle from the handle object.
|
||||
|
|
|
@ -22,7 +22,7 @@ Python release; this module helps to find out programmatically what the current
|
|||
grammar looks like.
|
||||
|
||||
An abstract syntax tree can be generated by passing :data:`ast.PyCF_ONLY_AST` as
|
||||
a flag to the :func:`compile` builtin function, or using the :func:`parse`
|
||||
a flag to the :func:`compile` built-in function, or using the :func:`parse`
|
||||
helper provided in this module. The result will be a tree of objects whose
|
||||
classes all inherit from :class:`ast.AST`. An abstract syntax tree can be
|
||||
compiled into a Python code object using the built-in :func:`compile` function.
|
||||
|
|
|
@ -509,7 +509,7 @@ stack manipulations such as ``dup``, ``drop``, ``swap``, ``over``, ``pick``,
|
|||
.. class:: defaultdict([default_factory[, ...]])
|
||||
|
||||
Returns a new dictionary-like object. :class:`defaultdict` is a subclass of the
|
||||
builtin :class:`dict` class. It overrides one method and adds one writable
|
||||
built-in :class:`dict` class. It overrides one method and adds one writable
|
||||
instance variable. The remaining functionality is the same as for the
|
||||
:class:`dict` class and is not documented here.
|
||||
|
||||
|
|
|
@ -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
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
.. 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
|
||||
:meth:`get` method which will override all others.
|
||||
|
||||
Sections are normally stored in a builtin dictionary. An alternative dictionary
|
||||
Sections are normally stored in a built-in dictionary. An alternative dictionary
|
||||
type can be passed to the :class:`ConfigParser` constructor. For example, if a
|
||||
dictionary type is passed that sorts its keys, the sections will be sorted on
|
||||
write-back, as will be the keys within each section.
|
||||
|
|
|
@ -609,9 +609,9 @@ the following methods:
|
|||
.. note::
|
||||
|
||||
A *character* means a C character (an ASCII code), rather then a Python
|
||||
character (a string of length 1). (This note is true whenever the documentation
|
||||
mentions a character.) The builtin :func:`ord` is handy for conveying strings to
|
||||
codes.
|
||||
character (a string of length 1). (This note is true whenever the
|
||||
documentation mentions a character.) The built-in :func:`ord` is handy for
|
||||
conveying strings to codes.
|
||||
|
||||
Paint character *ch* at ``(y, x)`` with attributes *attr*, overwriting any
|
||||
character previously painter at that location. By default, the character
|
||||
|
|
|
@ -847,7 +847,7 @@ available. They are listed here in alphabetical order.
|
|||
|
||||
.. 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
|
||||
statement and use the :func:`print` function, use this future statement at
|
||||
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
|
||||
.. sectionauthor:: Georg Brandl
|
||||
.. versionadded:: 2.6
|
||||
|
||||
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::
|
||||
|
||||
from future_builtins import map, filter
|
||||
|
@ -16,17 +16,17 @@ them from this module, like this::
|
|||
... code using Python 3-style map and filter ...
|
||||
|
||||
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::
|
||||
|
||||
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::
|
||||
|
||||
from __future__ import print_function
|
||||
|
||||
|
||||
Available builtins are:
|
||||
Available built-ins are:
|
||||
|
||||
.. function:: ascii(object)
|
||||
|
||||
|
@ -42,7 +42,7 @@ Available builtins are:
|
|||
|
||||
.. 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
|
||||
then converted to hexadecimal.
|
||||
|
||||
|
@ -52,7 +52,7 @@ Available builtins are:
|
|||
|
||||
.. 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
|
||||
then converted to octal.
|
||||
|
||||
|
|
|
@ -48,7 +48,7 @@ The :mod:`gc` module provides the following functions:
|
|||
The optional *generation* argument was added.
|
||||
|
||||
.. 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)
|
||||
is run. Not all items in some free lists may be freed due to the
|
||||
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]]]])
|
||||
|
||||
This installs the function :func:`_` in Python's builtin namespace, based on
|
||||
This installs the function :func:`_` in Python's builtins namespace, based on
|
||||
*domain*, *localedir*, and *codeset* which are passed to the function
|
||||
:func:`translation`. The *unicode* flag is passed to the resulting translation
|
||||
object's :meth:`install` method.
|
||||
|
@ -220,7 +220,7 @@ the built-in namespace as the function :func:`_`.
|
|||
print _('This string will be translated.')
|
||||
|
||||
For convenience, you want the :func:`_` function to be installed in Python's
|
||||
builtin namespace, so it is easily accessible in all modules of your
|
||||
builtins namespace, so it is easily accessible in all modules of your
|
||||
application.
|
||||
|
||||
.. versionchanged:: 2.4
|
||||
|
@ -347,7 +347,7 @@ are the methods of :class:`NullTranslations`:
|
|||
it binds :meth:`self.ugettext` instead. By default, *unicode* is false.
|
||||
|
||||
If the *names* parameter is given, it must be a sequence containing the
|
||||
names of functions you want to install in the builtin namespace in
|
||||
names of functions you want to install in the builtins namespace in
|
||||
addition to :func:`_`. Supported names are ``'gettext'`` (bound to
|
||||
:meth:`self.gettext` or :meth:`self.ugettext` according to the *unicode*
|
||||
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
|
||||
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.
|
||||
|
||||
|
||||
|
|
|
@ -79,7 +79,7 @@ approach to custom :keyword:`import` functions.
|
|||
|
||||
.. 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.
|
||||
|
||||
.. method:: BuiltinImporter.get_code(parent, modname, fqname)
|
||||
|
|
|
@ -10,7 +10,7 @@
|
|||
.. versionadded:: 2.6
|
||||
|
||||
The :mod:`io` module provides the Python interfaces to stream handling. The
|
||||
builtin :func:`open` function is defined in this module.
|
||||
built-in :func:`open` function is defined in this module.
|
||||
|
||||
At the top of the I/O hierarchy is the abstract base class :class:`IOBase`. It
|
||||
defines the basic interface to a stream. Note, however, that there is no
|
||||
|
|
|
@ -1555,8 +1555,8 @@ with the :class:`Pool` class.
|
|||
|
||||
.. method:: apply(func[, args[, kwds]])
|
||||
|
||||
Equivalent of the :func:`apply` builtin function. It blocks till the
|
||||
result is ready. Given this blocks - :meth:`apply_async` is better suited
|
||||
Equivalent of the :func:`apply` built-in function. It blocks till the
|
||||
result is ready. Given this blocks, :meth:`apply_async` is better suited
|
||||
for performing work in parallel. Additionally, the passed
|
||||
in function is only executed in one of the workers of the pool.
|
||||
|
||||
|
@ -1571,7 +1571,7 @@ with the :class:`Pool` class.
|
|||
|
||||
.. method:: map(func, iterable[, chunksize])
|
||||
|
||||
A parallel equivalent of the :func:`map` builtin function (it supports only
|
||||
A parallel equivalent of the :func:`map` built-in function (it supports only
|
||||
one *iterable* argument though). It blocks till the result is ready.
|
||||
|
||||
This method chops the iterable into a number of chunks which it submits to
|
||||
|
|
|
@ -24,7 +24,7 @@ The numeric tower
|
|||
.. class:: Complex
|
||||
|
||||
Subclasses of this type describe complex numbers and include the operations
|
||||
that work on the builtin :class:`complex` type. These are: conversions to
|
||||
that work on the built-in :class:`complex` type. These are: conversions to
|
||||
:class:`complex` and :class:`bool`, :attr:`.real`, :attr:`.imag`, ``+``,
|
||||
``-``, ``*``, ``/``, :func:`abs`, :meth:`conjugate`, ``==``, and ``!=``. All
|
||||
except ``-`` and ``!=`` are abstract.
|
||||
|
|
|
@ -13,7 +13,7 @@ Python data structures in a form which can be used as input to the interpreter.
|
|||
If the formatted structures include objects which are not fundamental Python
|
||||
types, the representation may not be loadable. This may be the case if objects
|
||||
such as files, sockets, classes, or instances are included, as well as many
|
||||
other builtin objects which are not representable as Python constants.
|
||||
other built-in objects which are not representable as Python constants.
|
||||
|
||||
The formatted representation keeps objects on a single line if it can, and
|
||||
breaks them onto multiple lines if they don't fit within the allowed width.
|
||||
|
|
|
@ -184,7 +184,7 @@ any iterable as an argument.
|
|||
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.
|
||||
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:
|
||||
|
|
|
@ -840,7 +840,7 @@ directly using only a single call on the :class:`Connection` object.
|
|||
Accessing columns by name instead of by index
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
One useful feature of the :mod:`sqlite3` module is the builtin
|
||||
One useful feature of the :mod:`sqlite3` module is the built-in
|
||||
:class:`sqlite3.Row` class designed to be used as a row factory.
|
||||
|
||||
Rows wrapped with this class can be accessed both by index (like tuples) and
|
||||
|
|
|
@ -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
|
||||
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.
|
||||
|
||||
+--------------------+---------------------------------+--------+
|
||||
|
@ -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,)``.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
other sequence-like behavior.
|
||||
|
||||
There are currently two builtin set types, :class:`set` and :class:`frozenset`.
|
||||
There are currently two built-in set types, :class:`set` and :class:`frozenset`.
|
||||
The :class:`set` type is mutable --- the contents can be changed using methods
|
||||
like :meth:`add` and :meth:`remove`. Since it is mutable, it has no hash value
|
||||
and cannot be used as either a dictionary key or as an element of another set.
|
||||
|
|
|
@ -312,7 +312,7 @@ Format Specification Mini-Language
|
|||
|
||||
"Format specifications" are used within replacement fields contained within a
|
||||
format string to define how individual values are presented (see
|
||||
:ref:`formatstrings`.) They can also be passed directly to the builtin
|
||||
:ref:`formatstrings`.) They can also be passed directly to the built-in
|
||||
:func:`format` function. Each formattable type may define how the format
|
||||
specification is to be interpreted.
|
||||
|
||||
|
|
|
@ -816,7 +816,7 @@ always available.
|
|||
|
||||
``'c_call'``
|
||||
A C function is about to be called. This may be an extension function or
|
||||
a builtin. *arg* is the C function object.
|
||||
a built-in. *arg* is the C function object.
|
||||
|
||||
``'c_return'``
|
||||
A C function has returned. *arg* is ``None``.
|
||||
|
|
|
@ -113,7 +113,7 @@ BuildApplication to combine all plugin modules to a single executable.
|
|||
: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.
|
||||
|
||||
.. deprecated:: 2.6
|
||||
|
|
|
@ -65,7 +65,7 @@ and regular expression pattern objects.
|
|||
.. versionchanged:: 2.4
|
||||
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::
|
||||
|
||||
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.
|
||||
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
|
||||
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.
|
||||
|
||||
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`,
|
||||
:file:`\*.py[co]`) and packages from ZIP-format archives. It is usually not
|
||||
needed to use the :mod:`zipimport` module explicitly; it is automatically used
|
||||
by the builtin :keyword:`import` mechanism for ``sys.path`` items that are paths
|
||||
by the built-in :keyword:`import` mechanism for ``sys.path`` items that are paths
|
||||
to ZIP archives.
|
||||
|
||||
Typically, ``sys.path`` is a list of directory names as strings. This module
|
||||
|
|
|
@ -1437,7 +1437,7 @@ Basic customization
|
|||
|
||||
.. 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
|
||||
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::
|
||||
|
||||
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`.
|
||||
|
||||
|
||||
|
@ -1865,12 +1865,12 @@ sequences, it should iterate through the values.
|
|||
|
||||
.. method:: object.__reversed__(self)
|
||||
|
||||
Called (if present) by the :func:`reversed` builtin to implement
|
||||
Called (if present) by the :func:`reversed` built-in to implement
|
||||
reverse iteration. It should return a new iterator object that iterates
|
||||
over all the objects in the container in reverse order.
|
||||
|
||||
If the :meth:`__reversed__` method is not provided, the :func:`reversed`
|
||||
builtin will fall back to using the sequence protocol (:meth:`__len__` and
|
||||
built-in will fall back to using the sequence protocol (:meth:`__len__` and
|
||||
:meth:`__getitem__`). Objects that support the sequence protocol should
|
||||
only provide :meth:`__reversed__` if they can provide an implementation
|
||||
that is more efficient than the one provided by :func:`reversed`.
|
||||
|
|
|
@ -112,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
|
||||
the statement refer to the binding of that name in the top-level namespace.
|
||||
Names are resolved in the top-level namespace by searching the global namespace,
|
||||
i.e. the namespace of the module containing the code block, and the builtin
|
||||
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
|
||||
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.
|
||||
|
||||
.. index:: pair: restricted; execution
|
||||
|
|
|
@ -665,7 +665,7 @@ the call.
|
|||
|
||||
.. note::
|
||||
|
||||
An implementation may provide builtin functions whose positional parameters do
|
||||
An implementation may provide built-in functions whose positional parameters do
|
||||
not have names, even if they are 'named' for the purpose of documentation, and
|
||||
which therefore cannot be supplied by keyword. In CPython, this is the case for
|
||||
functions implemented in C that use :cfunc:`PyArg_ParseTuple` to parse their
|
||||
|
@ -1032,7 +1032,7 @@ The operators ``<``, ``>``, ``==``, ``>=``, ``<=``, and ``!=`` compare the
|
|||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
another one is made arbitrarily but consistently within one execution of a
|
||||
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
|
||||
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
|
||||
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
|
||||
|
|
|
@ -86,7 +86,7 @@ source.
|
|||
|
||||
.. note::
|
||||
|
||||
This option cannot be used with builtin modules and extension modules
|
||||
This option cannot be used with built-in modules and extension modules
|
||||
written in C, since they do not have Python module files. However, it
|
||||
can still be used for precompiled modules, even if the original source
|
||||
file is not available.
|
||||
|
|
|
@ -1173,7 +1173,7 @@ Some of the more notable changes are:
|
|||
can uncomment them. Gestalt and Internet Config modules are enabled by
|
||||
default.
|
||||
|
||||
* Keyword arguments passed to builtin functions that don't take them now cause a
|
||||
* Keyword arguments passed to built-in functions that don't take them now cause a
|
||||
:exc:`TypeError` exception to be raised, with the message "*function* takes no
|
||||
keyword arguments".
|
||||
|
||||
|
|
|
@ -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
|
||||
http://www.json.org.
|
||||
|
||||
:mod:`json` comes with support for decoding and encoding most builtin Python
|
||||
:mod:`json` comes with support for decoding and encoding most built-in Python
|
||||
types. The following example encodes and decodes a dictionary::
|
||||
|
||||
>>> import json
|
||||
|
|
Loading…
Reference in New Issue