Kaydet (Commit) 21e99f49 authored tarafından Georg Brandl's avatar Georg Brandl

#5341: more built-in vs builtin fixes.

üst c02bbe32
......@@ -855,7 +855,7 @@ By default, ArgumentParser objects read command-line args in as simple strings.
However, quite often the command-line string should instead be interpreted as
another type, like a :class:`float`, :class:`int` or :class:`file`. The
``type`` keyword argument of :meth:`add_argument` allows any necessary
type-checking and type-conversions to be performed. Many common builtin types
type-checking and type-conversions to be performed. Many common built-in types
can be used directly as the value of the ``type`` argument::
>>> parser = argparse.ArgumentParser()
......
......@@ -119,7 +119,7 @@ searched. The global statement must precede all uses of the name.
.. index:: pair: restricted; execution
The built-in namespace associated with the execution of a code block is actually
The builtins namespace associated with the execution of a code block is actually
found by looking up the name ``__builtins__`` in its global namespace; this
should be a dictionary or a module (in the latter case the module's dictionary
is used). By default, when in the :mod:`__main__` module, ``__builtins__`` is
......@@ -131,7 +131,7 @@ weak form of restricted execution.
.. impl-detail::
Users should not touch ``__builtins__``; it is strictly an implementation
detail. Users wanting to override values in the built-in namespace should
detail. Users wanting to override values in the builtins namespace should
:keyword:`import` the :mod:`__builtin__` (no 's') module and modify its
attributes appropriately.
......
......@@ -109,9 +109,9 @@ are:
:func:`reduce` function.
Python 3.0 adds several new built-in functions and changes the
semantics of some existing built-ins. Functions that are new in 3.0
semantics of some existing builtins. Functions that are new in 3.0
such as :func:`bin` have simply been added to Python 2.6, but existing
built-ins haven't been changed; instead, the :mod:`future_builtins`
builtins haven't been changed; instead, the :mod:`future_builtins`
module has versions with the new 3.0 semantics. Code written to be
compatible with 3.0 can do ``from future_builtins import hex, map`` as
necessary.
......@@ -833,7 +833,7 @@ formatted. It receives a single argument, the format specifier::
else:
return str(self)
There's also a :func:`format` built-in that will format a single
There's also a :func:`format` builtin that will format a single
value. It calls the type's :meth:`__format__` method with the
provided specifier::
......@@ -1164,7 +1164,7 @@ access protocol. Abstract Base Classes (or ABCs) are an equivalent
feature for Python. The ABC support consists of an :mod:`abc` module
containing a metaclass called :class:`ABCMeta`, special handling of
this metaclass by the :func:`isinstance` and :func:`issubclass`
built-ins, and a collection of basic ABCs that the Python developers
builtins, and a collection of basic ABCs that the Python developers
think will be widely useful. Future versions of Python will probably
add more ABCs.
......@@ -1318,9 +1318,9 @@ an octal number, but it does add support for "0o" and "0b"::
>>> 0b101111
47
The :func:`oct` built-in still returns numbers
The :func:`oct` builtin still returns numbers
prefixed with a leading zero, and a new :func:`bin`
built-in returns the binary representation for a number::
builtin returns the binary representation for a number::
>>> oct(42)
'052'
......@@ -1329,7 +1329,7 @@ built-in returns the binary representation for a number::
>>> bin(173)
'0b10101101'
The :func:`int` and :func:`long` built-ins will now accept the "0o"
The :func:`int` and :func:`long` builtins will now accept the "0o"
and "0b" prefixes when base-8 or base-2 are requested, or when the
*base* argument is zero (signalling that the base used should be
determined from the string)::
......@@ -1415,7 +1415,7 @@ can be shifted left and right with ``<<`` and ``>>``,
combined using bitwise operations such as ``&`` and ``|``,
and can be used as array indexes and slice boundaries.
In Python 3.0, the PEP slightly redefines the existing built-ins
In Python 3.0, the PEP slightly redefines the existing builtins
:func:`round`, :func:`math.floor`, :func:`math.ceil`, and adds a new
one, :func:`math.trunc`, that's been backported to Python 2.6.
:func:`math.trunc` rounds toward zero, returning the closest
......@@ -1523,7 +1523,7 @@ Some smaller changes made to the core Python language are:
Previously this would have been a syntax error.
(Contributed by Amaury Forgeot d'Arc; :issue:`3473`.)
* A new built-in, ``next(iterator, [default])`` returns the next item
* A new builtin, ``next(iterator, [default])`` returns the next item
from the specified iterator. If the *default* argument is supplied,
it will be returned if *iterator* has been exhausted; otherwise,
the :exc:`StopIteration` exception will be raised. (Backported
......@@ -1952,9 +1952,9 @@ changes, or look through the Subversion logs for all the details.
(Contributed by Phil Schwartz; :issue:`1221598`.)
* The :func:`reduce` built-in function is also available in the
:mod:`functools` module. In Python 3.0, the built-in has been
:mod:`functools` module. In Python 3.0, the builtin has been
dropped and :func:`reduce` is only available from :mod:`functools`;
currently there are no plans to drop the built-in in the 2.x series.
currently there are no plans to drop the builtin in the 2.x series.
(Patched by Christian Heimes; :issue:`1739906`.)
* When possible, the :mod:`getpass` module will now use
......@@ -2756,7 +2756,7 @@ The functions in this module currently include:
* ``filter(predicate, iterable)``,
``map(func, iterable1, ...)``: the 3.0 versions
return iterators, unlike the 2.x built-ins which return lists.
return iterators, unlike the 2.x builtins which return lists.
* ``hex(value)``, ``oct(value)``: instead of calling the
:meth:`__hex__` or :meth:`__oct__` methods, these versions will
......
......@@ -195,7 +195,7 @@ class PyBuildExt(build_ext):
libraries=math_libs) )
# operator.add() and similar goodies
exts.append( Extension('operator', ['operator.c']) )
# access to the builtin codecs and codec registry
# access to the built-in codecs and codec registry
exts.append( Extension('_codecs', ['_codecsmodule.c']) )
# Python C API test module
exts.append( Extension('_testcapi', ['_testcapimodule.c']) )
......
This diff is collapsed.
......@@ -673,8 +673,8 @@ Core and Builtins
- Issue #4618: When unicode arguments are passed to print(), the default
separator and end should be unicode also.
- Issue #6119: Fixed a incorrect Py3k warning about order comparisons of builtin
functions and methods.
- Issue #6119: Fixed an incorrect Py3k warning about order comparisons of
built-in functions and methods.
- Issue #6347: Include inttypes.h as well as stdint.h in pyport.h.
This fixes a build failure on HP-UX: int32_t and uint32_t are
......@@ -778,7 +778,7 @@ Core and Builtins
correctly rounded.
- Issue #5787: object.__getattribute__(some_type, "__bases__") segfaulted on
some builtin types.
some built-in types.
- Issue #1869: fix a couple of minor round() issues. round(5e15+1)
was giving 5e15+2; round(-0.0) was losing the sign of the zero.
......@@ -3747,7 +3747,7 @@ Core and builtins
- Fixed a minor memory leak in dictobject.c. The content of the free
list was not freed on interpreter shutdown.
- Limit free list of method and builtin function objects to 256
- Limit free list of method and built-in function objects to 256
entries each.
- Patch #1953: Added ``sys._compact_freelists()`` and the C API
......@@ -3881,7 +3881,7 @@ Core and builtins
- Fix warnings found by the new version of the Coverity checker.
- The enumerate() builtin function is no longer bounded to sequences
- The enumerate() built-in function is no longer bounded to sequences
smaller than LONG_MAX. Formerly, it raised an OverflowError. Now,
automatically shifts from ints to longs.
......@@ -3942,7 +3942,7 @@ Core and builtins
- Deprecate BaseException.message as per PEP 352.
- Issue #1303614: don't expose object's __dict__ when the dict is
inherited from a builtin base.
inherited from a built-in base.
- When __slots__ are set to a unicode string, make it work the same as
setting a plain string, ie don't expand to single letter identifiers.
......@@ -4851,7 +4851,7 @@ Library
GNU modes.
- Bug #1586448: the compiler module now emits the same bytecode for
list comprehensions as the builtin compiler, using the LIST_APPEND
list comprehensions as the built-in compiler, using the LIST_APPEND
opcode.
- Fix codecs.EncodedFile which did not use file_encoding in 2.5.0, and
......@@ -5083,7 +5083,7 @@ Extension Modules
- Bug #1653736: Complain about keyword arguments to time.isoformat.
- Bug #1486663: don't reject keyword arguments for subclasses of
builtin types.
built-in types.
- Patch #1610575: The struct module now supports the 't' code, for C99
_Bool.
......@@ -5266,7 +5266,7 @@ Documentation
- Bug #1629566: clarify the docs on the return values of parsedate()
and parsedate_tz() in email.utils and rfc822.
- Patch #1671450: add a section about subclassing builtin types to the
- Patch #1671450: add a section about subclassing built-in types to the
"extending and embedding" tutorial.
- Bug #1629125: fix wrong data type (int -> Py_ssize_t) in PyDict_Next
......
......@@ -37,7 +37,7 @@ Py_TRACE_REFS introduced in 1.4
Turn on heavy reference debugging. This is major surgery. Every PyObject
grows two more pointers, to maintain a doubly-linked list of all live
heap-allocated objects. Most builtin type objects are not in this list,
heap-allocated objects. Most built-in type objects are not in this list,
as they're statically allocated. Starting in Python 2.3, if COUNT_ALLOCS
(see below) is also defined, a static type object T does appear in this
list if at least one object of type T has been created.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment