Skip to content

C
cpython
Kaydet (Commit) 27024916 authored tarafından Andrew M. Kuchling's avatar Andrew M. Kuchling
Dosyalara gözat
Seçenekler

Revision pass: lots of edits, typo fixes, rearrangements

üst fd25594a
Hide whitespace changes
Inline Side-by-side
Showing with 212 additions and 191 deletions
Doc/whatsnew/2.7.rst
Dosyayı görüntüle @ 27024916
......@@ -56,12 +56,7 @@ This article explains the new features in Python 2.7. The final
release of 2.7 is currently scheduled for July 2010; the detailed
schedule is described in :pep:`373`.
Python 2.7 is planned to be the last of the 2.x releases, so we worked
on making it a good release for the long term. To help with porting
to Python 3, several new features from the Python 3.x series have been
included in 2.7.
Numeric handling has been improved in many ways, both for
Numeric handling has been improved in many ways, for both
floating-point numbers and for the :class:`Decimal` class. There are
some useful additions to the standard library, such as a greatly
enhanced :mod:`unittest` module, the :mod:`argparse` module for
......@@ -69,6 +64,11 @@ parsing command-line options, convenient ordered-dictionary and
:class:`Counter` classes in the :mod:`collections` module, and many
other improvements.
Python 2.7 is planned to be the last of the 2.x releases, so we worked
on making it a good release for the long term. To help with porting
to Python 3, several new features from the Python 3.x series have been
included in 2.7.
This article doesn't attempt to provide a complete specification of
the new features, but instead provides a convenient overview. For
full details, you should refer to the documentation for Python 2.7 at
......@@ -98,7 +98,7 @@ Two consequences of the long-term significance of 2.7 are:
releases beyond the typical two years.
* A policy decision was made to silence warnings only of interest to
developers by default. :exc:`DeprecationWarning` and its
developers. :exc:`DeprecationWarning` and its
descendants are now ignored unless otherwise requested, preventing
users from seeing warnings triggered by an application. This change
was also made in the branch that will become Python 3.2. (Discussed
......@@ -113,13 +113,13 @@ Two consequences of the long-term significance of 2.7 are:
applications who are not directly involved in the development of
those applications. :exc:`DeprecationWarning` messages are
irrelevant to such users, making them worry about an application
that's actually working correctly and burdening the developers of
these applications with responding to these concerns.
that's actually working correctly and burdening application developers
with responding to these concerns.
You can re-enable display of :exc:`DeprecationWarning` messages by
running Python with the :option:`-Wdefault` (short form:
:option:`-Wd`) switch, or by setting the :envvar:`PYTHONWARNINGS`
environment variable to ``"default"`` or ``"d"``) before running
environment variable to ``"default"`` (or ``"d"``) before running
Python. Python code can also re-enable them
by calling ``warnings.simplefilter('default')``.
......@@ -139,24 +139,26 @@ A partial list of 3.1 features that were backported to 2.7:
* Multiple context managers in a single :keyword:`with` statement.
* A new version of the :mod:`io` library, rewritten in C for performance.
* The ordered-dictionary type described in :ref:`pep-0372`.
* The new format specifier described in :ref:`pep-0378`.
* The new ``","`` format specifier described in :ref:`pep-0378`.
* The :class:`memoryview` object.
* A small subset of the :mod:`importlib` module `described below <#importlib-section>`__.
* A small subset of the :mod:`importlib` module,
`described below <#importlib-section>`__.
* Float-to-string and string-to-float conversions now round their
results more correctly. And :func:`repr` of a floating-point
results more correctly, and :func:`repr` of a floating-point
number *x* returns a result that's guaranteed to round back to the
same number when converted back to a string.
* The :ctype:`PyCapsule` type, used to provide a C API for extension modules.
* The :cfunc:`PyLong_AsLongAndOverflow` C API function.
One porting change: the :option:`-3` switch now automatically
enables the :option:`-Qwarn` switch that causes warnings
about using classic division with integers and long integers.
Other new Python3-mode warnings include:
* :func:`operator.isCallable` and :func:`operator.sequenceIncludes`,
which are not supported in 3.x.
which are not supported in 3.x, now trigger warnings.
* The :option:`-3` switch now automatically
enables the :option:`-Qwarn` switch that causes warnings
about using classic division with integers and long integers.
.. ========================================================================
.. Large, PEP-level features and changes should be described here.
......@@ -170,16 +172,16 @@ PEP 372: Adding an Ordered Dictionary to collections
Regular Python dictionaries iterate over key/value pairs in arbitrary order.
Over the years, a number of authors have written alternative implementations
that remember the order that the keys were originally inserted. Based on
the experiences from those implementations, a new
:class:`~collections.OrderedDict` class has been introduced in the
:mod:`collections` module.
the experiences from those implementations, 2.7 introduces a new
:class:`~collections.OrderedDict` class in the :mod:`collections` module.
The :class:`~collections.OrderedDict` API is substantially the same as regular
dictionaries but will iterate over keys and values in a guaranteed order
The :class:`~collections.OrderedDict` API provides the same interface as regular
dictionaries but iterates over keys and values in a guaranteed order
depending on when a key was first inserted::
>>> from collections import OrderedDict
>>> d = OrderedDict([('first', 1), ('second', 2),
>>> d = OrderedDict([('first', 1),
... ('second', 2),
... ('third', 3)])
>>> d.items()
[('first', 1), ('second', 2), ('third', 3)]
......@@ -216,9 +218,11 @@ oldest key is selected::
Comparing two ordered dictionaries checks both the keys and values,
and requires that the insertion order was the same::
>>> od1 = OrderedDict([('first', 1), ('second', 2),
>>> od1 = OrderedDict([('first', 1),
... ('second', 2),
... ('third', 3)])
>>> od2 = OrderedDict([('third', 3), ('first', 1),
>>> od2 = OrderedDict([('third', 3),
... ('first', 1),
... ('second', 2)])
>>> od1 == od2
False
......@@ -239,9 +243,9 @@ remains O(1).
The standard library now supports use of ordered dictionaries in several
modules.
* The :mod:`ConfigParser` module uses them by default, letting
configuration files be read, modified, and then written back in their original
order.
* The :mod:`ConfigParser` module uses them by default, meaning that
configuration files can now read, modified, and then written back
in their original order.
* The :meth:`~collections.somenamedtuple._asdict()` method for
:func:`collections.namedtuple` now returns an ordered dictionary with the
......@@ -265,7 +269,7 @@ PEP 378: Format Specifier for Thousands Separator
=================================================
To make program output more readable, it can be useful to add
separators to large numbers and render them as
separators to large numbers, rendering them as
18,446,744,073,709,551,616 instead of 18446744073709551616.
The fully general solution for doing this is the :mod:`locale` module,
......@@ -301,13 +305,13 @@ PEP 389: The argparse Module for Parsing Command Lines
======================================================
The :mod:`argparse` module for parsing command-line arguments was
added, intended as a more powerful replacement for the
added as a more powerful replacement for the
:mod:`optparse` module.
This means Python now supports three different modules for parsing
command-line arguments: :mod:`getopt`, :mod:`optparse`, and
:mod:`argparse`. The :mod:`getopt` module closely resembles the C
:cfunc:`getopt` function, so it remains useful if you're writing a
library's :cfunc:`getopt` function, so it remains useful if you're writing a
Python prototype that will eventually be rewritten in C.
:mod:`optparse` becomes redundant, but there are no plans to remove it
because there are many scripts still using it, and there's no
......@@ -359,23 +363,28 @@ are automatically added, and produce neatly formatted output::
-o FILE direct output to FILE instead of stdout
-C NUM display NUM lines of added context
Similarly to :mod:`optparse`, the command-line switches and arguments
As with :mod:`optparse`, the command-line switches and arguments
are returned as an object with attributes named by the *dest* parameters::
-> ./python.exe argparse-example.py -v
{'output': None, 'is_verbose': True, 'context': 0, 'inputs': []}
{'output': None,
'is_verbose': True,
'context': 0,
'inputs': []}
-> ./python.exe argparse-example.py -v -o /tmp/output -C 4 file1 file2
{'output': '/tmp/output', 'is_verbose': True, 'context': 4,
{'output': '/tmp/output',
'is_verbose': True,
'context': 4,
'inputs': ['file1', 'file2']}
:mod:`argparse` has much fancier validation than :mod:`optparse`; you
can specify an exact number of arguments as an integer, 0 or more
arguments by passing ``'*'``, 1 or more by passing ``'+'``, or an
optional argument with ``'?'``. A top-level parser can contain
sub-parsers, so you can define subcommands that have different sets of
sub-parsers to define subcommands that have different sets of
switches, as in ``svn commit``, ``svn checkout``, etc. You can
specify an argument type as :class:`~argparse.FileType`, which will
specify an argument's type as :class:`~argparse.FileType`, which will
automatically open files for you and understands that ``'-'`` means
standard input or output.
......@@ -384,6 +393,8 @@ standard input or output.
`argparse module documentation <http://docs.python.org/dev/library/argparse.html>`__
`Upgrading optparse code to use argparse <http://docs.python.org/dev/library/argparse.html#upgrading-optparse-code>`__
Part of the Python documentation, describing how to convert
code that uses :mod:`optparse`.
:pep:`389` - argparse - New Command Line Parsing Module
PEP written and implemented by Steven Bethard.
......@@ -391,26 +402,25 @@ standard input or output.
PEP 391: Dictionary-Based Configuration For Logging
====================================================
.. not documented in library reference yet.
.. XXX not documented in library reference yet; add link here once it's added.
The :mod:`logging` module is very flexible; an application can define
The :mod:`logging` module is very flexible; applications can define
a tree of logging subsystems, and each logger in this tree can filter
out certain messages, format them differently, and direct messages to
a varying number of handlers.
All this flexibility can require a lot of configuration. You can
write Python statements to create objects and set their properties,
but a complex set-up would require verbose but boring code.
but a complex set-up requires verbose but boring code.
:mod:`logging` also supports a :func:`~logging.config.fileConfig`
function that parses a file, but the file format doesn't support
configuring filters, and it's messier to generate programmatically.
Python 2.7 adds a :func:`~logging.config.dictConfig` function that
uses a dictionary, and there are many ways to produce a dictionary
from different sources. You can construct one with code, of course.
Python's standard library now includes a JSON parser, so you could
parse a file containing JSON, or you could use a YAML parsing library
if one is installed.
uses a dictionary to configure logging. There are many ways to
produce a dictionary from different sources: construct one with code;
parse a file containing JSON; or use a YAML parsing library if one is
installed.
The following example configures two loggers, the root logger and a
logger named "network". Messages sent to the root logger will be
......@@ -424,17 +434,18 @@ that will be rotated once the log reaches 1Mb.
import logging.config
configdict = {
'version': 1, # Must be 1 at present
'version': 1, # Configuration schema in use; must be 1 for now
'formatters': {
'standard': {
'format': '%(asctime)s %(name)-15s %(levelname)-8s %(message)s'}},
'format': ('%(asctime)s %(name)-15s '
'%(levelname)-8s %(message)s')}},
'handlers': {'netlog': {'backupCount': 10,
'class': 'logging.handlers.RotatingFileHandler',
'filename': '/logs/network.log',
'formatter': 'standard',
'level': 'INFO',
'maxBytes': 1024*1024},
'class': 'logging.handlers.RotatingFileHandler',
'filename': '/logs/network.log',
'formatter': 'standard',
'level': 'INFO',
'maxBytes': 1024*1024},
'syslog': {'class': 'logging.handlers.SysLogHandler',
'formatter': 'standard',
'level': 'ERROR'}},
......@@ -497,7 +508,7 @@ instead of a fully materialized list.
It's not possible to change the return values of :meth:`keys`,
:meth:`values`, and :meth:`items` in Python 2.7 because too much code
would break. Instead the 3.x versions were added under the new names
of :meth:`viewkeys`, :meth:`viewvalues`, and :meth:`viewitems`.
:meth:`viewkeys`, :meth:`viewvalues`, and :meth:`viewitems`.
::
......@@ -507,8 +518,9 @@ of :meth:`viewkeys`, :meth:`viewvalues`, and :meth:`viewitems`.
>>> d.viewkeys()
dict_keys([0, 130, 10, 140, 20, 150, 30, ..., 250])
Views can be iterated over, but they also behave like sets. The ``&``
operator performs intersection, and ``|`` performs a union::
Views can be iterated over, but the key and item views also behave
like sets. The ``&`` operator performs intersection, and ``|``
performs a union::
>>> d1 = dict((i*10, chr(65+i)) for i in range(26))
>>> d2 = dict((i**.5, i) for i in range(1000))
......@@ -566,13 +578,13 @@ memory content that matches the :class:`bytes` type's interface.
>>> m2
<memory at 0x37f080>
The content of the view can be converted to a string of bytes or to
The content of the view can be converted to a string of bytes or
a list of integers:
>>> m2.tobytes()
'abcdefghijklmnopqrstuvwxyz'
>>> m2.tolist()
[97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122]
[97, 98, 99, 100, 101, 102, 103, ... 121, 122]
>>>
:class:`memoryview` objects allow modifying the underlying object if
......@@ -657,8 +669,8 @@ Some smaller changes made to the core Python language are:
in many different places: :func:`str` on
floats and complex numbers; the :class:`float` and :class:`complex`
constructors;
numeric formatting; serialization and
deserialization of floats and complex numbers using the
numeric formatting; serializing and
deserializing floats and complex numbers using the
:mod:`marshal`, :mod:`pickle`
and :mod:`json` modules;
parsing of float and imaginary literals in Python code;
......@@ -673,7 +685,7 @@ Some smaller changes made to the core Python language are:
.. maybe add an example?
The rounding library responsible for this improvement works on
Windows, and on Unix platforms using the gcc, icc, or suncc
Windows and on Unix platforms using the gcc, icc, or suncc
compilers. There may be a small number of platforms where correct
operation of this code cannot be guaranteed, so the code is not
used on such systems. You can find out which code is being used
......@@ -683,6 +695,33 @@ Some smaller changes made to the core Python language are:
Implemented by Eric Smith and Mark Dickinson, using David Gay's
:file:`dtoa.c` library; :issue:`7117`.
* Conversions from long integers and regular integers to floating
point now round differently, returning the floating-point number
closest to the number. This doesn't matter for small integers that
can be converted exactly, but for large numbers that will
unavoidably lose precision, Python 2.7 now approximates more
closely. For example, Python 2.6 computed the following::
>>> n = 295147905179352891391
>>> float(n)
2.9514790517935283e+20
>>> n - long(float(n))
65535L
Python 2.7's floating-point result is larger, but much closer to the
true value::
>>> n = 295147905179352891391
>>> float(n)
2.9514790517935289e+20
>>> n - long(float(n))
-1L
(Implemented by Mark Dickinson; :issue:`3166`.)
Integer division is also more accurate in its rounding behaviours. (Also
implemented by Mark Dickinson; :issue:`1811`.)
* The :meth:`str.format` method now supports automatic numbering of the replacement
fields. This makes using :meth:`str.format` more closely resemble using
``%s`` formatting::
......@@ -713,8 +752,8 @@ Some smaller changes made to the core Python language are:
A low-level change: the :meth:`object.__format__` method now triggers
a :exc:`PendingDeprecationWarning` if it's passed a format string,
because the :meth:`__format__` method for :class:`object` converts
the object to a string representation and formats that. The method
used to silently apply the format string to the string
the object to a string representation and formats that. Previously
the method silently applied the format string to the string
representation, but that could hide mistakes in Python code. If
you're supplying formatting information such as an alignment or
precision, presumably you're expecting the formatting to be applied
......@@ -737,33 +776,6 @@ Some smaller changes made to the core Python language are:
(Contributed by Fredrik Johansson and Victor Stinner; :issue:`3439`.)
* Conversions from long integers and regular integers to floating
point now round differently, returning the floating-point number
closest to the number. This doesn't matter for small integers that
can be converted exactly, but for large numbers that will
unavoidably lose precision, Python 2.7 now approximates more
closely. For example, Python 2.6 computed the following::
>>> n = 295147905179352891391
>>> float(n)
2.9514790517935283e+20
>>> n - long(float(n))
65535L
Python 2.7's floating-point result is larger, but much closer to the
true value::
>>> n = 295147905179352891391
>>> float(n)
2.9514790517935289e+20
>>> n - long(float(n))
-1L
(Implemented by Mark Dickinson; :issue:`3166`.)
Integer division is also more accurate in its rounding behaviours. (Also
implemented by Mark Dickinson; :issue:`1811`.)
* It's now possible for a subclass of the built-in :class:`unicode` type
to override the :meth:`__unicode__` method. (Implemented by
Victor Stinner; :issue:`1583863`.)
......@@ -796,7 +808,7 @@ Some smaller changes made to the core Python language are:
(fixed by Stefan Krah; :issue:`5677`).
* The Python tokenizer now translates line endings itself, so the
:func:`compile` built-in function can now accept code using any
:func:`compile` built-in function now accepts code using any
line-ending convention. Additionally, it no longer requires that the
code end in a newline.
......@@ -829,7 +841,7 @@ used with the :option:`-W` switch, separated by commas.
For example, the following setting will print warnings every time
they occur, but turn warnings from the :mod:`Cookie` module into an
error. (The exact syntax for setting an environment variable varies
across operating systems and shells, so it may be different for you.)
across operating systems and shells.)
::
......@@ -865,7 +877,7 @@ Several performance enhancements have been added:
any of them. This would previously take quadratic
time for garbage collection, but now the number of full garbage collections
is reduced as the number of objects on the heap grows.
The new logic is to only perform a full garbage collection pass when
The new logic only performs a full garbage collection pass when
the middle generation has been collected 10 times and when the
number of survivor objects from the middle generation exceeds 10% of
the number of objects in the oldest generation. (Suggested by Martin
......@@ -975,10 +987,10 @@ changes, or look through the Subversion logs for all the details.
The new version features better Python 3.x compatibility, various bug fixes,
and adds several new BerkeleyDB flags and methods.
(Updated by Jesús Cea Avión; :issue:`8156`. The pybsddb
changelog can be browsed at http://hg.jcea.es/pybsddb/file/tip/ChangeLog.)
changelog can be read at http://hg.jcea.es/pybsddb/file/tip/ChangeLog.)
* The :mod:`bz2` module's :class:`~bz2.BZ2File` now supports the context
management protocol, so you can write ``with bz2.BZ2File(...) as f: ...``.
management protocol, so you can write ``with bz2.BZ2File(...) as f:``.
(Contributed by Hagen Fürstenau; :issue:`3860`.)
* New class: the :class:`~collections.Counter` class in the :mod:`collections`
......@@ -1003,7 +1015,7 @@ changes, or look through the Subversion logs for all the details.
>>> c['z']
0
There are three additional :class:`~collections.Counter` methods:
There are three additional :class:`~collections.Counter` methods.
:meth:`~collections.Counter.most_common` returns the N most common
elements and their counts. :meth:`~collections.Counter.elements`
returns an iterator over the contained elements, repeating each
......@@ -1030,12 +1042,20 @@ changes, or look through the Subversion logs for all the details.
.. revision 79660
The new :class:`~collections.OrderedDict` class is described in the earlier
New class: :class:`~collections.OrderedDict` is described in the earlier
section :ref:`pep-0372`.
New method: The :class:`~collections.deque` data type now has a
:meth:`~collections.deque.count` method that returns the number of
contained elements equal to the supplied argument *x*, and a
:meth:`~collections.deque.reverse` method that reverses the elements
of the deque in-place. :class:`deque` also exposes its maximum
length as the read-only :attr:`~collections.deque.maxlen` attribute.
(Both features added by Raymond Hettinger.)
The :class:`~collections.namedtuple` class now has an optional *rename* parameter.
If *rename* is true, field names that are invalid because they've
been repeated or that aren't legal Python identifiers will be
been repeated or aren't legal Python identifiers will be
renamed to legal names that are derived from the field's
position within the list of fields:
......@@ -1046,14 +1066,6 @@ changes, or look through the Subversion logs for all the details.
(Added by Raymond Hettinger; :issue:`1818`.)
The :class:`~collections.deque` data type now has a
:meth:`~collections.deque.count` method that returns the number of
contained elements equal to the supplied argument *x*, and a
:meth:`~collections.deque.reverse` method that reverses the elements
of the deque in-place. :class:`deque` also exposes its maximum
length as the read-only :attr:`~collections.deque.maxlen` attribute.
(Both features added by Raymond Hettinger.)
* Constructors for the parsing classes in the :mod:`ConfigParser` module now
take a *allow_no_value* parameter, defaulting to false; if true,
options without values will be allowed. For example::
......@@ -1074,14 +1086,14 @@ changes, or look through the Subversion logs for all the details.
>>> print config.get('mysqld', 'unknown')
Traceback (most recent call last):
...
ConfigParser.NoOptionError: No option 'unknown' in section: 'mysqld'
NoOptionError: No option 'unknown' in section: 'mysqld'
(Contributed by Mats Kindahl; :issue:`7005`.)
* Deprecated function: :func:`contextlib.nested`, which allows
handling more than one context manager with a single :keyword:`with`
statement, has been deprecated, because :keyword:`with` supports
multiple context managers syntactically now.
statement, has been deprecated, because the :keyword:`with` statement
now supports multiple context managers.
* The :mod:`copy` module's :func:`~copy.deepcopy` function will now
correctly copy bound instance methods. (Implemented by
......@@ -1101,7 +1113,7 @@ changes, or look through the Subversion logs for all the details.
* New method: the :class:`~decimal.Decimal` class gained a
:meth:`~decimal.Decimal.from_float` class method that performs an exact
conversion of a floating-point number to a :class:`~decimal.Decimal`.
Note that this is an **exact** conversion that strives for the
This exact conversion strives for the
closest decimal approximation to the floating-point representation's value;
the resulting decimal value will therefore still include the inaccuracy,
if any.
......@@ -1119,19 +1131,19 @@ changes, or look through the Subversion logs for all the details.
:class:`Decimal`.
(Fixed by Mark Dickinson; :issue:`2531`.)
Most of the methods of the :class:`~decimal.Context` class now accept integers
as well as :class:`~decimal.Decimal` instances; the only exceptions are the
:meth:`~decimal.Context.canonical` and :meth:`~decimal.Context.is_canonical`
methods. (Patch by Juan José Conti; :issue:`7633`.)
The constructor for :class:`~decimal.Decimal` now accepts
floating-point numbers (added by Raymond Hettinger; :issue:`8257`)
and non-European Unicode characters such as Arabic-Indic digits
(contributed by Mark Dickinson; :issue:`6595`).
Most of the methods of the :class:`~decimal.Context` class now accept integers
as well as :class:`~decimal.Decimal` instances; the only exceptions are the
:meth:`~decimal.Context.canonical` and :meth:`~decimal.Context.is_canonical`
methods. (Patch by Juan José Conti; :issue:`7633`.)
When using :class:`~decimal.Decimal` instances with a string's
:meth:`~str.format` method, the default alignment was previously
left-alignment. This has been changed to right-alignment, which seems
left-alignment. This has been changed to right-alignment, which is
more sensible for numeric types. (Changed by Mark Dickinson; :issue:`6857`.)
Comparisons involving a signaling NaN value (or ``sNAN``) now signal
......@@ -1156,17 +1168,18 @@ changes, or look through the Subversion logs for all the details.
rationals added in :issue:`5812`, and float/decimal in
:issue:`8294`.)
An oversight was fixed, making the :class:`Fraction` match the other
numeric types; ordering comparisons (``<``, ``<=``, ``>``, ``>=``) between
Ordering comparisons (``<``, ``<=``, ``>``, ``>=``) between
fractions and complex numbers now raise a :exc:`TypeError`.
This fixes an oversight, making the :class:`Fraction` match the other
numeric types.
.. revision 79455
* New class: a new :class:`~ftplib.FTP_TLS` class in
* New class: :class:`~ftplib.FTP_TLS` in
the :mod:`ftplib` module provides secure FTP
connections using TLS encapsulation of authentication as well as
subsequent control and data transfers.
(Contributed by Giampaolo Rodola', :issue:`2054`.)
(Contributed by Giampaolo Rodola; :issue:`2054`.)
The :meth:`~ftplib.FTP.storbinary` method for binary uploads can now restart
uploads thanks to an added *rest* parameter (patch by Pablo Mouzo;
......@@ -1192,7 +1205,7 @@ changes, or look through the Subversion logs for all the details.
otherwise. (Contributed by Antoine Pitrou; :issue:`4688`.)
* The :mod:`gzip` module's :class:`~gzip.GzipFile` now supports the context
management protocol, so you can write ``with gzip.GzipFile(...) as f: ...``
management protocol, so you can write ``with gzip.GzipFile(...) as f:``
(contributed by Hagen Fürstenau; :issue:`3860`), and it now implements
the :class:`io.BufferedIOBase` ABC, so you can wrap it with
:class:`io.BufferedReader` for faster processing
......@@ -1208,7 +1221,7 @@ changes, or look through the Subversion logs for all the details.
* New attribute: the :mod:`hashlib` module now has an :attr:`~hashlib.hashlib.algorithms`
attribute containing a tuple naming the supported algorithms.
In Python 2.7, ``hashlib.algorithms`` contains
``('md5', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512')``
``('md5', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512')``.
(Contributed by Carl Chenet; :issue:`7418`.)
* The default :class:`~httplib.HTTPResponse` class used by the :mod:`httplib` module now
......@@ -1221,7 +1234,7 @@ changes, or look through the Subversion logs for all the details.
(Contributed by Eldon Ziegler; :issue:`3972`.)
* The :mod:`ihooks` module now supports relative imports. Note that
:mod:`ihooks` is an older module used to support customizing imports,
:mod:`ihooks` is an older module for customizing imports,
superseded by the :mod:`imputil` module added in Python 2.0.
(Relative import support added by Neil Schemenauer.)
......@@ -1239,9 +1252,9 @@ changes, or look through the Subversion logs for all the details.
>>> def f(a, b=1, *pos, **named):
... pass
>>> getcallargs(f, 1, 2, 3)
{'a': 1, 'named': {}, 'b': 2, 'pos': (3,)}
{'a': 1, 'b': 2, 'pos': (3,), 'named': {}}
>>> getcallargs(f, a=2, x=4)
{'a': 2, 'named': {'x': 4}, 'b': 1, 'pos': ()}
{'a': 2, 'b': 1, 'pos': (), 'named': {'x': 4}}
>>> getcallargs(f)
Traceback (most recent call last):
...
......@@ -1292,8 +1305,8 @@ changes, or look through the Subversion logs for all the details.
floats or :class:`~decimal.Decimal` instances. (Implemented by Raymond
Hettinger; :issue:`5032`.)
:func:`itertools.combinations` and :func:`itertools.product` were
previously raising :exc:`ValueError` for values of *r* larger than
:func:`itertools.combinations` and :func:`itertools.product`
previously raised :exc:`ValueError` for values of *r* larger than
the input iterable. This was deemed a specification error, so they
now return an empty iterator. (Fixed by Raymond Hettinger; :issue:`4816`.)
......@@ -1343,7 +1356,8 @@ changes, or look through the Subversion logs for all the details.
real, effective, and saved GIDs and UIDs;
:func:`~os.setresgid` and :func:`~os.setresuid`, which set
real, effective, and saved GIDs and UIDs to new values;
:func:`~os.initgroups`. (GID/UID functions
:func:`~os.initgroups`, which initialize the group access list
for the current process. (GID/UID functions
contributed by Travis H.; :issue:`6508`. Support for initgroups added
by Jean-Paul Calderone; :issue:`7333`.)
......@@ -1393,9 +1407,9 @@ changes, or look through the Subversion logs for all the details.
* New functions: in the :mod:`site` module, three new functions
return various site- and user-specific paths.
:func:`~site.getsitepackages` returns a list containing all
global site-packages directories, and
global site-packages directories,
:func:`~site.getusersitepackages` returns the path of the user's
site-packages directory.
site-packages directory, and
:func:`~site.getuserbase` returns the value of the :envvar:`USER_BASE`
environment variable, giving the path to a directory that can be used
to store data.
......@@ -1461,7 +1475,7 @@ changes, or look through the Subversion logs for all the details.
Another change makes the extension load all of OpenSSL's ciphers and
digest algorithms so that they're all available. Some SSL
certificates couldn't be verified, reporting an 'unknown algorithm'
certificates couldn't be verified, reporting an "unknown algorithm"
error. (Reported by Beda Kosata, and fixed by Antoine Pitrou;
:issue:`8484`.)
......@@ -1531,7 +1545,7 @@ changes, or look through the Subversion logs for all the details.
:mod:`tarfile` now supports filtering the :class:`~tarfile.TarInfo`
objects being added to a tar file. When you call :meth:`~tarfile.TarFile.add`,
instance, you may supply an optional *filter* argument
you may supply an optional *filter* argument
that's a callable. The *filter* callable will be passed the
:class:`~tarfile.TarInfo` for every file being added, and can modify and return it.
If the callable returns ``None``, the file will be excluded from the
......@@ -1609,7 +1623,7 @@ changes, or look through the Subversion logs for all the details.
(Contributed by Kristján Valur Jónsson; :issue:`6267`.)
* The :mod:`zipfile` module's :class:`~zipfile.ZipFile` now supports the context
management protocol, so you can write ``with zipfile.ZipFile(...) as f: ...``.
management protocol, so you can write ``with zipfile.ZipFile(...) as f:``.
(Contributed by Brian Curtin; :issue:`5511`.)
:mod:`zipfile` now also supports archiving empty directories and
......@@ -1661,9 +1675,9 @@ Here are some examples::
>>> anydbm
<module 'anydbm' from '/p/python/Lib/anydbm.py'>
>>> # Relative import
>>> sysconfig = import_module('..sysconfig', 'distutils.command')
>>> sysconfig
<module 'distutils.sysconfig' from '/p/python/Lib/distutils/sysconfig.pyc'>
>>> file_util = import_module('..file_util', 'distutils.command')
>>> file_util
<module 'distutils.file_util' from '/python/Lib/distutils/file_util.pyc'>
:mod:`importlib` was implemented by Brett Cannon and introduced in
Python 3.1.
......@@ -1710,7 +1724,7 @@ set was originally called Tile, but was renamed to Ttk (for "themed Tk")
on being added to Tcl/Tck release 8.5.
To learn more, read the :mod:`ttk` module documentation. You may also
wish to read Tcl/Tk manual page describing the
wish to read the Tcl/Tk manual page describing the
Ttk theme engine, available at
http://www.tcl.tk/man/tcl8.5/TkCmd/ttk_intro.htm. Some
screenshots of the Python/Ttk code in use are at
......@@ -1751,17 +1765,17 @@ The :func:`main` function supports some other new options:
* :option:`-b` or :option:`--buffer` will buffer the standard output
and standard error streams during each test. If the test passes,
any resulting output will be discard; on failure, the buffered
any resulting output will be discarded; on failure, the buffered
output will be displayed.
* :option:`-c` or :option:`--catch` will cause the control-C interrupt
to be handled more gracefully. Instead of interrupting the test
process immediately, the currently running test will be completed
and then the resulting partial results will be reported. If you're
impatient, a second press of control-C will cause an immediate
and then the partial results up to the interruption will be reported.
If you're impatient, a second press of control-C will cause an immediate
interruption.
This control-C handler tries to avoid interfering when the code
This control-C handler tries to avoid causing problems when the code
being tested or the tests being run have defined a signal handler of
their own, by noticing that a signal handler was already set and
calling it. If this doesn't work for you, there's a
......@@ -1773,12 +1787,12 @@ The :func:`main` function supports some other new options:
continuing to execute further tests. (Suggested by Cliff Dyer and
implemented by Michael Foord; :issue:`8074`.)
The progress messages now shows 'x' for expected failures
The progress messages now show 'x' for expected failures
and 'u' for unexpected successes when run in verbose mode.
(Contributed by Benjamin Peterson.)
Test cases can raise the :exc:`~unittest.SkipTest` exception to skip a
test. (:issue:`1034053`.)
test (:issue:`1034053`).
The error messages for :meth:`~unittest.TestCase.assertEqual`,
:meth:`~unittest.TestCase.assertTrue`, and :meth:`~unittest.TestCase.assertFalse`
......@@ -1788,7 +1802,7 @@ True, both the standard error message and any additional message you
provide will be printed for failures. (Added by Michael Foord; :issue:`5663`.)
The :meth:`~unittest.TestCase.assertRaises` method now
return a context handler when called without providing a callable
returns a context handler when called without providing a callable
object to run. For example, you can write this::
with self.assertRaises(KeyError):
......@@ -1808,7 +1822,7 @@ different module or class.
The methods :meth:`~unittest.TestCase.addCleanup` and
:meth:`~unittest.TestCase.doCleanups` were added.
:meth:`~unittest.TestCase.addCleanup` allows you to add cleanup functions that
:meth:`~unittest.TestCase.addCleanup` lets you add cleanup functions that
will be called unconditionally (after :meth:`~unittest.TestCase.setUp` if
:meth:`~unittest.TestCase.setUp` fails, otherwise after :meth:`~unittest.TestCase.tearDown`). This allows
for much simpler resource allocation and deallocation during tests
......@@ -1887,13 +1901,13 @@ GvR worked on merging them into Python's version of :mod:`unittest`.
objects being compared are of the specified type. This function
should compare the two objects and raise an exception if they don't
match; it's a good idea for the function to provide additional
information about why the two objects are matching, much as the new
information about why the two objects aren't matching, much as the new
sequence comparison methods do.
:func:`unittest.main` now takes an optional ``exit`` argument. If
False, :func:`~unittest.main` doesn't call :func:`sys.exit`, allowing it to be
used from the interactive interpreter. (Contributed by J. Pablo
Fernández; :issue:`3379`.)
False, :func:`~unittest.main` doesn't call :func:`sys.exit`, allowing
:func:`main` to be used from the interactive interpreter.
(Contributed by J. Pablo Fernández; :issue:`3379`.)
:class:`~unittest.TestResult` has new :meth:`~unittest.TestResult.startTestRun` and
:meth:`~unittest.TestResult.stopTestRun` methods that are called immediately before
......@@ -1916,17 +1930,17 @@ Updated module: ElementTree 1.3
---------------------------------
The version of the ElementTree library included with Python was updated to
version 1.3. Some of the new features in ElementTree 1.3 are:
version 1.3. Some of the new features are:
* The various parsing functions now take a *parser* keyword argument
that can be used to provide an :class:`XMLParser` instance that will
be used. This makes it possible to override the file's internal encoding:
giving an :class:`XMLParser` instance that will
be used. This makes it possible to override the file's internal encoding::
p = ET.XMLParser(encoding='utf-8')
t = ET.XML("""<root/>""", parser=p)
Errors in parsing XML now raise a :exc:`ParseError` exception.
Instances of :exc:`ParseError` have a :attr:`position` attribute
Errors in parsing XML now raise a :exc:`ParseError` exception, whose
instances have a :attr:`position` attribute
containing a (*line*, *column*) tuple giving the location of the problem.
* ElementTree's code for converting trees to a string has been
......@@ -1937,15 +1951,15 @@ version 1.3. Some of the new features in ElementTree 1.3 are:
elements as ``<empty></empty>`` instead of ``<empty/>``, and text
mode will skip over elements and only output the text chunks. If
you set the :attr:`tag` attribute of an element to ``None`` but
leaves its children in place, the element will be omitted when the
leave its children in place, the element will be omitted when the
tree is written out, so you don't need to do more extensive rearrangement
to remove a single element.
Namespace aspects have also been improved. All the ``xmlns:<whatever>``
declarations are now put on the root element and not scattered throughout
the resulting output. You can set the default namespace for a tree
Namespace handling has also been improved. All ``xmlns:<whatever>``
declarations are now output on the root element, not scattered throughout
the resulting XML. You can set the default namespace for a tree
by setting the :attr:`default_namespace` attribute and can
register new prefixes with :meth:`regsiter_namespace`. In XML mode,
register new prefixes with :meth:`register_namespace`. In XML mode,
you can use the true/false *xml_declaration* parameter to suppress the
XML declaration.
......@@ -1967,10 +1981,9 @@ version 1.3. Some of the new features in ElementTree 1.3 are:
* New :class:`Element` method: :meth:`iter` yields the children of the
element as a generator. It's also possible to write ``for child in
elem: ...`` to loop over an element's children. The existing method
:meth:`getiterator` is now deprecated. :meth:`getchildren` is
another similar method that constructs and returns a list of
children; it's also deprecated.
elem:`` to loop over an element's children. The existing method
:meth:`getiterator` is now deprecated, as is :meth:`getchildren`
which constructs and returns a list of children.
* New :class:`Element` method: :meth:`itertext` yields all chunks of
text that are descendants of the element. For example::
......@@ -1982,13 +1995,13 @@ version 1.3. Some of the new features in ElementTree 1.3 are:
# Outputs ['\n ', '1', ' ', '2', ' ', '3', '\n']
print list(t.itertext())
* Deprecated: using an element as a Boolean (i.e., ``if elem: ...``)
would return true if the element had any children, or false if
there were no children. This behaviour will eventually change or be removed
because it's confusing (``None`` is false, but so is a childless element?),
so it will now trigger a :exc:`FutureWarning`. In your code,
you should be explicit: write ``len(elem) != 0`` if you're interested in
the number of children, or ``elem is not None`` Instead,
* Deprecated: using an element as a Boolean (i.e., ``if elem:``) would
return true if the element had any children, or false if there were
no children. This behaviour is confusing -- ``None`` is false, but
so is a childless element? -- so it will now trigger a
:exc:`FutureWarning`. In your code, you should be explicit: write
``len(elem) != 0`` if you're interested in the number of children,
or ``elem is not None``.
Fredrik Lundh develops ElementTree and produced the 1.3 version;
you can read his article describing 1.3 at
......@@ -2009,9 +2022,9 @@ Changes to Python's build process and to the C API include:
<http://sourceware.org/gdb/current/onlinedocs/gdb/Python.html>`__.
When you begin debugging an executable program P, GDB will look for
a file named ``P-gdb.py`` and automatically read it. Dave Malcolm
contributed a :file:`python-gdb.py` that adds a number of useful
commands when debugging Python itself. For example, there are
``py-up`` and ``py-down`` that go up or down one Python stack frame,
contributed a :file:`python-gdb.py` that adds a number of
commands useful when debugging Python itself. For example,
``py-up`` and ``py-down`` go up or down one Python stack frame,
which usually corresponds to several C stack frames. ``py-print``
prints the value of a Python variable, and ``py-bt`` prints the
Python stack trace. (Added as a result of :issue:`8032`.)
......@@ -2028,7 +2041,7 @@ Changes to Python's build process and to the C API include:
* New function: :cfunc:`PyCode_NewEmpty` creates an empty code object;
only the filename, function name, and first line number are required.
This is useful to extension modules that are attempting to
This is useful for extension modules that are attempting to
construct a more useful traceback stack. Previously such
extensions needed to call :cfunc:`PyCode_New`, which had many
more arguments. (Added by Jeffrey Yasskin.)
......@@ -2036,7 +2049,7 @@ Changes to Python's build process and to the C API include:
* New function: :cfunc:`PyErr_NewExceptionWithDoc` creates a new
exception class, just as the existing :cfunc:`PyErr_NewException` does,
but takes an extra ``char *`` argument containing the docstring for the
new exception class. (Added by the 'lekma' user on the Python bug tracker;
new exception class. (Added by 'lekma' on the Python bug tracker;
:issue:`7033`.)
* New function: :cfunc:`PyFrame_GetLineNumber` takes a frame object
......@@ -2078,11 +2091,11 @@ Changes to Python's build process and to the C API include:
* Removed function: :cmacro:`PyEval_CallObject` is now only available
as a macro. A function version was being kept around to preserve
ABI linking compatibility, but that was in 1997; it can certainly be
deleted. (Removed by Antoine Pitrou; :issue:`8276`.)
deleted by now. (Removed by Antoine Pitrou; :issue:`8276`.)
* New format codes: the :cfunc:`PyFormat_FromString`,
:cfunc:`PyFormat_FromStringV`, and :cfunc:`PyErr_Format` now
accepts ``%lld`` and ``%llu`` format codes for displaying values of
:cfunc:`PyFormat_FromStringV`, and :cfunc:`PyErr_Format` functions now
accept ``%lld`` and ``%llu`` format codes for displaying
C's :ctype:`long long` types.
(Contributed by Mark Dickinson; :issue:`7228`.)
......@@ -2096,7 +2109,7 @@ Changes to Python's build process and to the C API include:
ever release the lock, since the other threads weren't replicated,
and the child process would no longer be able to perform imports.
Python 2.7 now acquires the import lock before performing an
Python 2.7 acquires the import lock before performing an
:func:`os.fork`, and will also clean up any locks created using the
:mod:`threading` module. C extension modules that have internal
locks, or that call :cfunc:`fork()` themselves, will not benefit
......@@ -2123,15 +2136,15 @@ Changes to Python's build process and to the C API include:
building the :mod:`pyexpat` module to use the system Expat library.
(Contributed by Arfrever Frehtes Taifersar Arahesis; :issue:`7609`.)
* New configure option: compiling Python with the
* New configure option: the
:option:`--with-valgrind` option will now disable the pymalloc
allocator, which is difficult for the Valgrind memory-error detector
to analyze correctly.
Valgrind will therefore be better at detecting memory leaks and
overruns. (Contributed by James Henstridge; :issue:`2422`.)
* New configure option: you can now supply no arguments to
:option:`--with-dbmliborder=` in order to build none of the various
* New configure option: you can now supply an empty string to
:option:`--with-dbmliborder=` in order to disable all of the various
DBM modules. (Added by Arfrever Frehtes Taifersar Arahesis;
:issue:`6491`.)
......@@ -2158,15 +2171,15 @@ Capsules
-------------------
Python 3.1 adds a new C datatype, :ctype:`PyCapsule`, for providing a
C API to an extension module. A capsule is essentially the holder for
a C ``void *`` pointer, and is bound to a module attribute; for
C API to an extension module. A capsule is essentially the holder of
a C ``void *`` pointer, and is made available as a module attribute; for
example, the :mod:`socket` module's API is exposed as ``socket.CAPI``,
and :mod:`unicodedata` calls it ``ucnhash_CAPI``. Other extensions
and :mod:`unicodedata` exposes ``ucnhash_CAPI``. Other extensions
can import the module, access its dictionary to get the capsule
object, and then get the ``void *`` pointer, which will usually point
to an array of pointers to the various API functions.
to an array of pointers to the module's various API functions.
There is an existing data type that already does this,
There is an existing data type already used for this,
:ctype:`PyCObject`, but it doesn't provide type safety. Evil code
written in pure Python could cause a segmentation fault by taking a
:ctype:`PyCObject` from module A and somehow substituting it for the
......@@ -2224,10 +2237,10 @@ Port-Specific Changes: Windows
* The :func:`os.kill` function now works on Windows. The signal value
can be the constants :const:`CTRL_C_EVENT`,
:const:`CTRL_BREAK_EVENT`, or any integer. The Control-C and
Control-Break keystroke events can be sent to subprocesses; any
other value will use the :cfunc:`TerminateProcess` API.
(Contributed by Miki Tebeka; :issue:`1220212`.)
:const:`CTRL_BREAK_EVENT`, or any integer. The first two constants
will send Control-C and Control-Break keystroke events to
subprocesses; any other value will use the :cfunc:`TerminateProcess`
API. (Contributed by Miki Tebeka; :issue:`1220212`.)
* The :func:`os.listdir` function now correctly fails
for an empty path. (Fixed by Hirokazu Yamamoto; :issue:`5913`.)
......@@ -2259,7 +2272,7 @@ Other Changes and Fixes
* Two benchmark scripts, :file:`iobench` and :file:`ccbench`, were
added to the :file:`Tools` directory. :file:`iobench` measures the
speed of built-in file I/O objects (as returned by :func:`open`)
speed of the built-in file I/O objects returned by :func:`open`
while performing various operations, and :file:`ccbench` is a
concurrency benchmark that tries to measure computing throughput,
thread switching latency, and IO processing bandwidth when
......@@ -2354,6 +2367,14 @@ In the standard library:
identifier instead of the previous default value of ``'python'``.
(Changed by Sean Reifschneider; :issue:`8451`.)
* The :mod:`tarfile` module's default error handling has changed, to
no longer suppress fatal errors. The default error level was previously 0,
which meant that errors would only result in a message being written to the
debug log, but because the debug log is not activated by default,
these errors go unnoticed. The default error level is now 1,
which raises an exception if there's an error.
(Changed by Lars Gustäbel; :issue:`7357`.)
* The :mod:`urlparse` module's :func:`~urlparse.urlsplit` now handles
unknown URL schemes in a fashion compliant with :rfc:`3986`: if the
URL is of the form ``"<something>://..."``, the text before the
......
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