Recorded merge of revisions 78024 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk ........ r78024 | georg.brandl | 2010-02-06 19:44:44 +0100 (Sa, 06 Feb 2010) | 1 line #5341: fix "builtin" where used as an adjective ("built-in" is correct). ........
This commit is contained in:
parent
3102bd9afe
commit
c4a55fccab
|
@ -354,7 +354,7 @@ optionally followed by an import of the module::
|
|||
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 */
|
||||
|
|
|
@ -649,9 +649,10 @@ order to remind you of that fact, it does not return the sorted list. This way,
|
|||
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]...
|
||||
|
|
|
@ -441,7 +441,7 @@ extension module using g++ (e.g., ``g++ -shared -o mymodule.so mymodule.o``).
|
|||
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)
|
||||
|
|
|
@ -25,10 +25,10 @@ your topic of interest will usually find something helpful.
|
|||
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:
|
||||
|
||||
|
@ -361,7 +361,7 @@ therefore atomic from the point of view of a Python program.
|
|||
|
||||
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,
|
||||
|
@ -504,9 +504,9 @@ I can't seem to use os.read() on a pipe created with os.popen(); why?
|
|||
|
||||
: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.
|
||||
|
@ -607,10 +607,11 @@ Python file objects are a high-level layer of abstraction on top of C streams,
|
|||
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
|
||||
|
|
|
@ -178,9 +178,10 @@ it is much shorter and far faster to use ::
|
|||
|
||||
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)]
|
||||
|
@ -203,7 +204,7 @@ manipulating strings, use the ``replace()`` and the ``format()`` :ref:`methods
|
|||
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.
|
||||
|
@ -361,7 +362,7 @@ Though a bit surprising at first, a moment's consideration explains this. On
|
|||
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.
|
||||
|
||||
|
@ -1033,7 +1034,7 @@ trailing newline from a string.
|
|||
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...
|
||||
|
|
|
@ -315,7 +315,7 @@ Glossary
|
|||
|
||||
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
|
||||
|
|
|
@ -52,10 +52,10 @@ One of the most awful question asked on the newsgroup is why this code::
|
|||
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
|
||||
|
|
|
@ -241,8 +241,8 @@ The following exceptions are the exceptions that are usually raised.
|
|||
|
||||
.. 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
|
||||
|
|
|
@ -43,7 +43,7 @@ The :mod:`gc` module provides the following functions:
|
|||
: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`.
|
||||
|
|
|
@ -87,7 +87,7 @@ attributes:
|
|||
| 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 |
|
||||
|
|
|
@ -953,7 +953,7 @@ definition, function definition, or :keyword:`import` statement.
|
|||
**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.
|
||||
|
|
|
@ -717,7 +717,7 @@ object that defines the method :meth:`__next__` which accesses elements in the
|
|||
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)
|
||||
|
|
|
@ -270,7 +270,7 @@ changed.
|
|||
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
|
||||
|
@ -383,10 +383,10 @@ New Syntax
|
|||
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
|
||||
--------------
|
||||
|
@ -506,7 +506,7 @@ consulted for longer descriptions.
|
|||
* :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
|
||||
|
@ -521,7 +521,7 @@ consulted for longer descriptions.
|
|||
|
||||
* :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.
|
||||
|
||||
|
@ -615,7 +615,7 @@ review:
|
|||
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`,
|
||||
|
@ -795,8 +795,8 @@ Builtins
|
|||
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`.
|
||||
|
||||
|
|
|
@ -85,7 +85,7 @@ Support was also added for third-party tools like `PyYAML <http://pyyaml.org/>`_
|
|||
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::
|
||||
|
|
Loading…
Reference in New Issue