int
main(int argc, char *argv[])
{
- /* Add a builtin module, before Py_Initialize */
+ /* Add a built-in module, before Py_Initialize */
PyImport_AppendInittab("spam", PyInit_spam);
/* Pass argv[0] to the Python interpreter */
you won't be fooled into accidentally overwriting a list when you need a sorted
copy but also need to keep the unsorted version around.
-In Python 2.4 a new builtin -- :func:`sorted` -- has been added. This function
-creates a new list from a provided iterable, sorts it and returns it. For
-example, here's how to iterate over the keys of a dictionary in sorted order::
+In Python 2.4 a new built-in function -- :func:`sorted` -- has been added.
+This function creates a new list from a provided iterable, sorts it and returns
+it. For example, here's how to iterate over the keys of a dictionary in sorted
+order::
for key in sorted(mydict):
... # do whatever with mydict[key]...
Can I create an object class with some methods implemented in C and others in Python (e.g. through inheritance)?
----------------------------------------------------------------------------------------------------------------
-In Python 2.2, you can inherit from builtin classes such as :class:`int`,
+In Python 2.2, you can inherit from built-in classes such as :class:`int`,
:class:`list`, :class:`dict`, etc.
The Boost Python Library (BPL, http://www.boost.org/libs/python/doc/index.html)
Where is the math.py (socket.py, regex.py, etc.) source file?
-------------------------------------------------------------
-If you can't find a source file for a module it may be a builtin or dynamically
-loaded module implemented in C, C++ or other compiled language. In this case
-you may not have the source file or it may be something like mathmodule.c,
-somewhere in a C source directory (not on the Python Path).
+If you can't find a source file for a module it may be a built-in or
+dynamically loaded module implemented in C, C++ or other compiled language.
+In this case you may not have the source file or it may be something like
+mathmodule.c, somewhere in a C source directory (not on the Python Path).
There are (at least) three kinds of modules in Python:
In theory, this means an exact accounting requires an exact understanding of the
PVM bytecode implementation. In practice, it means that operations on shared
-variables of builtin data types (ints, lists, dicts, etc) that "look atomic"
+variables of built-in data types (ints, lists, dicts, etc) that "look atomic"
really are.
For example, the following operations are all atomic (L, L1, L2 are lists, D,
:func:`os.read` is a low-level function which takes a file descriptor, a small
integer representing the opened file. :func:`os.popen` creates a high-level
-file object, the same type returned by the builtin :func:`open` function. Thus,
-to read n bytes from a pipe p created with :func:`os.popen`, you need to use
-``p.read(n)``.
+file object, the same type returned by the built-in :func:`open` function.
+Thus, to read n bytes from a pipe p created with :func:`os.popen`, you need to
+use ``p.read(n)``.
.. XXX update to use subprocess. See the :ref:`subprocess-replacements` section.
which in turn are a medium-level layer of abstraction on top of (among other
things) low-level C file descriptors.
-For most file objects you create in Python via the builtin ``open`` constructor,
-``f.close()`` marks the Python file object as being closed from Python's point
-of view, and also arranges to close the underlying C stream. This also happens
-automatically in f's destructor, when f becomes garbage.
+For most file objects you create in Python via the built-in ``open``
+constructor, ``f.close()`` marks the Python file object as being closed from
+Python's point of view, and also arranges to close the underlying C stream.
+This also happens automatically in ``f``'s destructor, when ``f`` becomes
+garbage.
But stdin, stdout and stderr are treated specially by Python, because of the
special status also given to them by C. Running ``sys.stdout.close()`` marks
L2 = list(L1[:3]) # "list" is redundant if L1 is a list.
-Note that the functionally-oriented builtins such as :func:`map`, :func:`zip`,
-and friends can be a convenient accelerator for loops that perform a single
-task. For example to pair the elements of two lists together::
+Note that the functionally-oriented built-in functions such as :func:`map`,
+:func:`zip`, and friends can be a convenient accelerator for loops that
+perform a single task. For example to pair the elements of two lists
+together::
>>> list(zip([1, 2, 3], [4, 5, 6]))
[(1, 4), (2, 5), (3, 6)]
on string objects <string-methods>`. Use regular expressions only when you're
not dealing with constant string patterns.
-Be sure to use the :meth:`list.sort` builtin method to do sorting, and see the
+Be sure to use the :meth:`list.sort` built-in method to do sorting, and see the
`sorting mini-HOWTO <http://wiki.python.org/moin/HowTo/Sorting>`_ for examples
of moderately advanced usage. :meth:`list.sort` beats other techniques for
sorting in all but the most extreme circumstances.
one hand, requiring :keyword:`global` for assigned variables provides a bar
against unintended side-effects. On the other hand, if ``global`` was required
for all global references, you'd be using ``global`` all the time. You'd have
-to declare as global every reference to a builtin function or to a component of
+to declare as global every reference to a built-in function or to a component of
an imported module. This clutter would defeat the usefulness of the ``global``
declaration for identifying side-effects.
How do I iterate over a sequence in reverse order?
--------------------------------------------------
-Use the :func:`reversed` builtin function, which is new in Python 2.4::
+Use the :func:`reversed` built-in function, which is new in Python 2.4::
for x in reversed(sequence):
... # do something with x...
iterator
An object representing a stream of data. Repeated calls to the iterator's
- :meth:`__next__` (or passing it to the builtin function) :func:`next`
+ :meth:`__next__` (or passing it to the built-in function) :func:`next`
method return successive items in the stream. When no more data are
available a :exc:`StopIteration` exception is raised instead. At this
point, the iterator object is exhausted and any further calls to its
f.read()
does not work. Of course, it works just fine (assuming you have a file called
-"www".) But it does not work if somewhere in the module, the statement ``from os
-import *`` is present. The :mod:`os` module has a function called :func:`open`
-which returns an integer. While it is very useful, shadowing builtins is one of
-its least useful properties.
+"www".) But it does not work if somewhere in the module, the statement ``from
+os import *`` is present. The :mod:`os` module has a function called
+:func:`open` which returns an integer. While it is very useful, shadowing a
+builtin is one of its least useful properties.
Remember, you can never know for sure what names a module exports, so either
take what you need --- ``from module import name1, name2``, or keep them in the
.. exception:: StopIteration
- Raised by builtin :func:`next` and an :term:`iterator`\'s :meth:`__next__`
- method to signal that there are no further values.
+ Raised by built-in function :func:`next` and an :term:`iterator`\'s
+ :meth:`__next__` method to signal that there are no further values.
.. exception:: SyntaxError
:exc:`ValueError` is raised if the generation number is invalid. The number of
unreachable objects found is returned.
- 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:`float`.
| frame | f_back | next outer frame object |
| | | (this frame's caller) |
+-----------+-----------------+---------------------------+
-| | f_builtins | built-in namespace seen |
+| | f_builtins | builtins namespace seen |
| | | by this frame |
+-----------+-----------------+---------------------------+
| | f_code | code object being |
**Programmer's note:** the :keyword:`global` is a directive to the parser. It
applies only to code parsed at the same time as the :keyword:`global` statement.
In particular, a :keyword:`global` statement contained in a string or code
-object supplied to the builtin :func:`exec` function does not affect the code
+object supplied to the built-in :func:`exec` function does not affect the code
block *containing* the function call, and code contained in such a string is
unaffected by :keyword:`global` statements in the code containing the function
call. The same applies to the :func:`eval` and :func:`compile` functions.
container one at a time. When there are no more elements, :meth:`__next__`
raises a :exc:`StopIteration` exception which tells the :keyword:`for` loop to
terminate. You can call the :meth:`__next__` method using the :func:`next`
-builtin; this example shows how it all works::
+built-in function; this example shows how it all works::
>>> s = 'abc'
>>> it = iter(s)
single "euro" character. (Of course, this change only affects raw
string literals; the euro character is ``'\u20ac'`` in Python 3.0.)
-* The builtin :class:`basestring` abstract type was removed. Use
+* The built-in :class:`basestring` abstract type was removed. Use
:class:`str` instead. The :class:`str` and :class:`bytes` types
don't have functionality enough in common to warrant a shared base
class. The ``2to3`` tool (see below) replaces every occurrence of
literals (``0720``) are gone.
* New binary literals, e.g. ``0b1010`` (already in 2.6), and
- there is a new corresponding builtin function, :func:`bin`.
+ there is a new corresponding built-in function, :func:`bin`.
* Bytes literals are introduced with a leading ``b`` or ``B``, and
- there is a new corresponding builtin function, :func:`bytes`.
+ there is a new corresponding built-in function, :func:`bytes`.
Changed Syntax
--------------
* :ref:`pep-3116`. The :mod:`io` module is now the standard way of
doing file I/O, and the initial values of :data:`sys.stdin`,
:data:`sys.stdout` and :data:`sys.stderr` are now instances of
- :class:`io.TextIOBase`. The builtin :func:`open` function is now an
+ :class:`io.TextIOBase`. The built-in :func:`open` function is now an
alias for :func:`io.open` and has additional keyword arguments
*encoding*, *errors*, *newline* and *closefd*. Also note that an
invalid *mode* argument now raises :exc:`ValueError`, not
* :ref:`pep-3119`. The :mod:`abc` module and the ABCs defined in the
:mod:`collections` module plays a somewhat more prominent role in
- the language now, and builtin collection types like :class:`dict`
+ the language now, and built-in collection types like :class:`dict`
and :class:`list` conform to the :class:`collections.MutableMapping`
and :class:`collections.MutableSequence` ABCs, respectively.
Some other changes to standard library modules, not covered by
:pep:`3108`:
-* Killed :mod:`sets`. Use the builtin :func:`set` function.
+* Killed :mod:`sets`. Use the built-in :func:`set` class.
* Cleanup of the :mod:`sys` module: removed :func:`sys.exitfunc`,
:func:`sys.exc_clear`, :data:`sys.exc_type`, :data:`sys.exc_value`,
It raises :exc:`EOFError` if the input is terminated prematurely.
To get the old behavior of :func:`input`, use ``eval(input())``.
-* A new builtin :func:`next` was added to call the :meth:`__next__`
- method on an object.
+* A new built-in function :func:`next` was added to call the
+ :meth:`__next__` method on an object.
* Moved :func:`intern` to :func:`sys.intern`.
PEP 378: Format Specifier for Thousands Separator
=================================================
-The builtin :func:`format` function and the :meth:`str.format` method use
+The built-in :func:`format` function and the :meth:`str.format` method use
a mini-language that now includes a simple, non-locale aware way to format
a number with a thousands separator. That provides a way to humanize a
program's output, improving its professional appearance and readability::
projects / python / commitdiff