Issue #21569: sync Python 2.7 What's New with 2.7 version
This commit is contained in:
parent
1462786f00
commit
024b2f52bf
|
@ -7,7 +7,6 @@
|
|||
.. hyperlink all the methods & functions.
|
||||
|
||||
.. T_STRING_INPLACE not described in main docs
|
||||
.. "Format String Syntax" in string.rst could use many more examples.
|
||||
|
||||
.. $Id$
|
||||
Rules for maintenance:
|
||||
|
@ -50,17 +49,16 @@
|
|||
This saves the maintainer some effort going through the SVN logs
|
||||
when researching a change.
|
||||
|
||||
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`.
|
||||
This article explains the new features in Python 2.7. Python 2.7 was released
|
||||
on July 3, 2010.
|
||||
|
||||
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
|
||||
parsing command-line options, convenient ordered-dictionary and
|
||||
:class:`Counter` classes in the :mod:`collections` module, and many
|
||||
other improvements.
|
||||
floating-point numbers and for the :class:`~decimal.Decimal` class.
|
||||
There are some useful additions to the standard library, such as a
|
||||
greatly enhanced :mod:`unittest` module, the :mod:`argparse` module
|
||||
for parsing command-line options, convenient :class:`~collections.OrderedDict`
|
||||
and :class:`~collections.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
|
||||
|
@ -81,45 +79,91 @@ bug/patch item for each change.
|
|||
The Future for Python 2.x
|
||||
=========================
|
||||
|
||||
Python 2.7 is intended to be the last major release in the 2.x series.
|
||||
The Python maintainers are planning to focus their future efforts on
|
||||
the Python 3.x series.
|
||||
Python 2.7 is the last major release in the 2.x series, as the Python
|
||||
maintainers have shifted the focus of their new feature development efforts
|
||||
to the Python 3.x series. This means that while Python 2 continues to
|
||||
receive bug fixes, and to be updated to build correctly on new hardware and
|
||||
versions of supported operated systems, there will be no new full feature
|
||||
releases for the language or standard library.
|
||||
|
||||
This means that 2.7 will remain in place for a long time, running
|
||||
production systems that have not been ported to Python 3.x.
|
||||
Two consequences of the long-term significance of 2.7 are:
|
||||
However, while there is a large common subset between Python 2.7 and Python
|
||||
3, and many of the changes involved in migrating to that common subset, or
|
||||
directly to Python 3, can be safely automated, some other changes (notably
|
||||
those associated with Unicode handling) may require careful consideration,
|
||||
and preferably robust automated regression test suites, to migrate
|
||||
effectively.
|
||||
|
||||
* It's very likely the 2.7 release will have a longer period of
|
||||
maintenance compared to earlier 2.x versions. Python 2.7 will
|
||||
continue to be maintained while the transition to 3.x continues, and
|
||||
the developers are planning to support Python 2.7 with bug-fix
|
||||
releases beyond the typical two years.
|
||||
This means that Python 2.7 will remain in place for a long time, providing a
|
||||
stable and supported base platform for production systems that have not yet
|
||||
been ported to Python 3. The full expected lifecycle of the Python 2.7
|
||||
series is detailed in :pep:`373`.
|
||||
|
||||
* A policy decision was made to silence warnings only of interest to
|
||||
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
|
||||
on stdlib-sig and carried out in :issue:`7319`.)
|
||||
Some key consequences of the long-term significance of 2.7 are:
|
||||
|
||||
In previous releases, :exc:`DeprecationWarning` messages were
|
||||
enabled by default, providing Python developers with a clear
|
||||
indication of where their code may break in a future major version
|
||||
of Python.
|
||||
* As noted above, the 2.7 release has a much longer period of maintenance
|
||||
when compared to earlier 2.x versions. Python 2.7 is currently expected to
|
||||
remain supported by the core development team (receiving security updates
|
||||
and other bug fixes) until at least 2020 (10 years after its initial
|
||||
release, compared to the more typical support period of 18-24 months).
|
||||
|
||||
However, there are increasingly many users of Python-based
|
||||
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 application developers
|
||||
with responding to these concerns.
|
||||
* As the Python 2.7 standard library ages, making effective use of the
|
||||
Python Package Index (either directly or via a redistributor) becomes
|
||||
more important for Python 2 users. In addition to a wide variety of third
|
||||
party packages for various tasks, the available packages include backports
|
||||
of new modules and features from the Python 3 standard library that are
|
||||
compatible with Python 2, as well as various tools and libraries that can
|
||||
make it easier to migrate to Python 3. The `Python Packaging User Guide
|
||||
<https://packaging.python.org>`__ provides guidance on downloading and
|
||||
installing software from the Python Package Index.
|
||||
|
||||
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
|
||||
Python. Python code can also re-enable them
|
||||
by calling ``warnings.simplefilter('default')``.
|
||||
* While the preferred approach to enhancing Python 2 is now the publication
|
||||
of new packages on the Python Package Index, this approach doesn't
|
||||
necessarily work in all cases, especially those related to network
|
||||
security. In exceptional cases that cannot be handled adequately by
|
||||
publishing new or updated packages on PyPI, the Python Enhancement
|
||||
Proposal process may be used to make the case for adding new features
|
||||
directly to the Python 2 standard library. Any such additions, and the
|
||||
maintenance releases where they were added, will be noted in the
|
||||
:ref:`py27-maintenance-enhancements` section below.
|
||||
|
||||
For projects wishing to migrate from Python 2 to Python 3, or for library
|
||||
and framework developers wishing to support users on both Python 2 and
|
||||
Python 3, there are a variety of tools and guides available to help decide
|
||||
on a suitable approach and manage some of the technical details involved.
|
||||
The recommended starting point is the :ref:`pyporting-howto` HOWTO guide.
|
||||
|
||||
|
||||
Changes to the Handling of Deprecation Warnings
|
||||
===============================================
|
||||
|
||||
For Python 2.7, a policy decision was made to silence warnings only of
|
||||
interest to developers by default. :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 became Python 3.2. (Discussed
|
||||
on stdlib-sig and carried out in :issue:`7319`.)
|
||||
|
||||
In previous releases, :exc:`DeprecationWarning` messages were
|
||||
enabled by default, providing Python developers with a clear
|
||||
indication of where their code may break in a future major version
|
||||
of Python.
|
||||
|
||||
However, there are increasingly many users of Python-based
|
||||
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 application developers
|
||||
with responding to these concerns.
|
||||
|
||||
You can re-enable display of :exc:`DeprecationWarning` messages by
|
||||
running Python with the :option:`-Wdefault <-W>` (short form:
|
||||
:option:`-Wd <-W>`) switch, or by setting the :envvar:`PYTHONWARNINGS`
|
||||
environment variable to ``"default"`` (or ``"d"``) before running
|
||||
Python. Python code can also re-enable them
|
||||
by calling ``warnings.simplefilter('default')``.
|
||||
|
||||
The ``unittest`` module also automatically reenables deprecation warnings
|
||||
when running tests.
|
||||
|
||||
|
||||
Python 3.1 Features
|
||||
|
@ -133,7 +177,7 @@ for migrating to the 3.x series.
|
|||
A partial list of 3.1 features that were backported to 2.7:
|
||||
|
||||
* The syntax for set literals (``{1,2,3}`` is a mutable set).
|
||||
* Dictionary and set comprehensions (``{ i: i*2 for i in range(3)}``).
|
||||
* Dictionary and set comprehensions (``{i: i*2 for i in range(3)}``).
|
||||
* 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`.
|
||||
|
@ -155,7 +199,7 @@ Other new Python3-mode warnings include:
|
|||
* :func:`operator.isCallable` and :func:`operator.sequenceIncludes`,
|
||||
which are not supported in 3.x, now trigger warnings.
|
||||
* The :option:`-3` switch now automatically
|
||||
enables the :option:`-Qwarn` switch that causes warnings
|
||||
enables the :option:`-Qwarn <-Q>` switch that causes warnings
|
||||
about using classic division with integers and long integers.
|
||||
|
||||
|
||||
|
@ -390,9 +434,10 @@ standard input or output.
|
|||
|
||||
.. seealso::
|
||||
|
||||
`argparse module documentation <http://docs.python.org/dev/library/argparse.html>`__
|
||||
:mod:`argparse` documentation
|
||||
The documentation page of the argparse module.
|
||||
|
||||
`Upgrading optparse code to use argparse <http://docs.python.org/dev/library/argparse.html#upgrading-optparse-code>`__
|
||||
:ref:`argparse-from-optparse`
|
||||
Part of the Python documentation, describing how to convert
|
||||
code that uses :mod:`optparse`.
|
||||
|
||||
|
@ -402,8 +447,6 @@ standard input or output.
|
|||
PEP 391: Dictionary-Based Configuration For Logging
|
||||
====================================================
|
||||
|
||||
.. XXX not documented in library reference yet; add link here once it's added.
|
||||
|
||||
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
|
||||
|
@ -412,21 +455,21 @@ 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 requires verbose but boring code.
|
||||
:mod:`logging` also supports a :func:`~logging.config.fileConfig`
|
||||
:mod:`logging` also supports a :func:`~logging.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
|
||||
Python 2.7 adds a :func:`~logging.dictConfig` function that
|
||||
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.
|
||||
installed. For more information see :ref:`logging-config-api`.
|
||||
|
||||
The following example configures two loggers, the root logger and a
|
||||
logger named "network". Messages sent to the root logger will be
|
||||
logger named "network". Messages sent to the root logger will be
|
||||
sent to the system log using the syslog protocol, and messages
|
||||
to the "network" logger will be written to a :file:`network.log` file
|
||||
that will be rotated once the log reaches 1Mb.
|
||||
that will be rotated once the log reaches 1MB.
|
||||
|
||||
::
|
||||
|
||||
|
@ -445,7 +488,7 @@ that will be rotated once the log reaches 1Mb.
|
|||
'filename': '/logs/network.log',
|
||||
'formatter': 'standard',
|
||||
'level': 'INFO',
|
||||
'maxBytes': 1024*1024},
|
||||
'maxBytes': 1000000},
|
||||
'syslog': {'class': 'logging.handlers.SysLogHandler',
|
||||
'formatter': 'standard',
|
||||
'level': 'ERROR'}},
|
||||
|
@ -483,16 +526,19 @@ implemented by Vinay Sajip, are:
|
|||
for UDP or :const:`socket.SOCK_STREAM` for TCP. The default
|
||||
protocol remains UDP.
|
||||
|
||||
* :class:`Logger` instances gained a :meth:`getChild` method that retrieves a
|
||||
descendant logger using a relative path. For example,
|
||||
once you retrieve a logger by doing ``log = getLogger('app')``,
|
||||
* :class:`~logging.Logger` instances gained a :meth:`~logging.Logger.getChild`
|
||||
method that retrieves a descendant logger using a relative path.
|
||||
For example, once you retrieve a logger by doing ``log = getLogger('app')``,
|
||||
calling ``log.getChild('network.listen')`` is equivalent to
|
||||
``getLogger('app.network.listen')``.
|
||||
|
||||
* The :class:`LoggerAdapter` class gained a :meth:`isEnabledFor` method
|
||||
that takes a *level* and returns whether the underlying logger would
|
||||
* The :class:`~logging.LoggerAdapter` class gained a
|
||||
:meth:`~logging.LoggerAdapter.isEnabledFor` method that takes a
|
||||
*level* and returns whether the underlying logger would
|
||||
process a message of that level of importance.
|
||||
|
||||
.. XXX: Logger objects don't have a class declaration so the link don't work
|
||||
|
||||
.. seealso::
|
||||
|
||||
:pep:`391` - Dictionary-Based Configuration For Logging
|
||||
|
@ -501,14 +547,15 @@ implemented by Vinay Sajip, are:
|
|||
PEP 3106: Dictionary Views
|
||||
====================================================
|
||||
|
||||
The dictionary methods :meth:`keys`, :meth:`values`, and :meth:`items`
|
||||
are different in Python 3.x. They return an object called a :dfn:`view`
|
||||
instead of a fully materialized list.
|
||||
The dictionary methods :meth:`~dict.keys`, :meth:`~dict.values`, and
|
||||
:meth:`~dict.items` are different in Python 3.x. They return an object
|
||||
called a :dfn:`view` 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
|
||||
:meth:`viewkeys`, :meth:`viewvalues`, and :meth:`viewitems`.
|
||||
It's not possible to change the return values of :meth:`~dict.keys`,
|
||||
:meth:`~dict.values`, and :meth:`~dict.items` in Python 2.7 because
|
||||
too much code would break. Instead the 3.x versions were added
|
||||
under the new names :meth:`~dict.viewkeys`, :meth:`~dict.viewvalues`,
|
||||
and :meth:`~dict.viewitems`.
|
||||
|
||||
::
|
||||
|
||||
|
@ -550,8 +597,8 @@ over the view::
|
|||
RuntimeError: dictionary changed size during iteration
|
||||
|
||||
You can use the view methods in Python 2.x code, and the 2to3
|
||||
converter will change them to the standard :meth:`keys`,
|
||||
:meth:`values`, and :meth:`items` methods.
|
||||
converter will change them to the standard :meth:`~dict.keys`,
|
||||
:meth:`~dict.values`, and :meth:`~dict.items` methods.
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
@ -624,7 +671,7 @@ Some smaller changes made to the core Python language are:
|
|||
``{}`` continues to represent an empty dictionary; use
|
||||
``set()`` for an empty set.
|
||||
|
||||
>>> {1,2,3,4,5}
|
||||
>>> {1, 2, 3, 4, 5}
|
||||
set([1, 2, 3, 4, 5])
|
||||
>>> set() # empty set
|
||||
set([])
|
||||
|
@ -794,7 +841,7 @@ Some smaller changes made to the core Python language are:
|
|||
``None`` as its first argument. (Fixed by Georg Brandl;
|
||||
:issue:`4759`.)
|
||||
|
||||
.. bytearray doesn't seem to be documented
|
||||
.. XXX bytearray doesn't seem to be documented
|
||||
|
||||
* When using ``@classmethod`` and ``@staticmethod`` to wrap
|
||||
methods as class or static methods, the wrapper object now
|
||||
|
@ -867,12 +914,6 @@ Optimizations
|
|||
|
||||
Several performance enhancements have been added:
|
||||
|
||||
.. * A new :program:`configure` option, :option:`--with-computed-gotos`,
|
||||
compiles the main bytecode interpreter loop using a new dispatch
|
||||
mechanism that gives speedups of up to 20%, depending on the system
|
||||
and benchmark. The new mechanism is only supported on certain
|
||||
compilers, such as gcc, SunPro, and icc.
|
||||
|
||||
* A new opcode was added to perform the initial setup for
|
||||
:keyword:`with` statements, looking up the :meth:`__enter__` and
|
||||
:meth:`__exit__` methods. (Contributed by Benjamin Peterson.)
|
||||
|
@ -1054,7 +1095,7 @@ changes, or look through the Subversion logs for all the details.
|
|||
: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
|
||||
of the deque in-place. :class:`~collections.deque` also exposes its maximum
|
||||
length as the read-only :attr:`~collections.deque.maxlen` attribute.
|
||||
(Both features added by Raymond Hettinger.)
|
||||
|
||||
|
@ -1135,15 +1176,14 @@ changes, or look through the Subversion logs for all the details.
|
|||
``Decimal('0.1000000000000000055511151231257827021181583404541015625')``.
|
||||
(Implemented by Raymond Hettinger; :issue:`4796`.)
|
||||
|
||||
Comparing instances of :class:`Decimal` with floating-point
|
||||
Comparing instances of :class:`~decimal.Decimal` with floating-point
|
||||
numbers now produces sensible results based on the numeric values
|
||||
of the operands. Previously such comparisons would fall back to
|
||||
Python's default rules for comparing objects, which produced arbitrary
|
||||
results based on their type. Note that you still cannot combine
|
||||
:class:`Decimal` and floating-point in other operations such as addition,
|
||||
since you should be explicitly choosing how to convert between float and
|
||||
:class:`Decimal`.
|
||||
(Fixed by Mark Dickinson; :issue:`2531`.)
|
||||
:class:`~decimal.Decimal`. (Fixed by Mark Dickinson; :issue:`2531`.)
|
||||
|
||||
The constructor for :class:`~decimal.Decimal` now accepts
|
||||
floating-point numbers (added by Raymond Hettinger; :issue:`8257`)
|
||||
|
@ -1195,8 +1235,8 @@ changes, or look through the Subversion logs for all the details.
|
|||
|
||||
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.
|
||||
This fixes an oversight, making the :class:`~fractions.Fraction`
|
||||
match the other numeric types.
|
||||
|
||||
.. revision 79455
|
||||
|
||||
|
@ -1210,7 +1250,7 @@ changes, or look through the Subversion logs for all the details.
|
|||
uploads thanks to an added *rest* parameter (patch by Pablo Mouzo;
|
||||
:issue:`6845`.)
|
||||
|
||||
* New class decorator: :func:`total_ordering` in the :mod:`functools`
|
||||
* New class decorator: :func:`~functools.total_ordering` in the :mod:`functools`
|
||||
module takes a class that defines an :meth:`__eq__` method and one of
|
||||
:meth:`__lt__`, :meth:`__le__`, :meth:`__gt__`, or :meth:`__ge__`,
|
||||
and generates the missing comparison methods. Since the
|
||||
|
@ -1218,7 +1258,7 @@ changes, or look through the Subversion logs for all the details.
|
|||
this decorator makes it easier to define ordered classes.
|
||||
(Added by Raymond Hettinger; :issue:`5479`.)
|
||||
|
||||
New function: :func:`cmp_to_key` will take an old-style comparison
|
||||
New function: :func:`~functools.cmp_to_key` will take an old-style comparison
|
||||
function that expects two arguments and return a new callable that
|
||||
can be used as the *key* parameter to functions such as
|
||||
:func:`sorted`, :func:`min` and :func:`max`, etc. The primary
|
||||
|
@ -1345,7 +1385,7 @@ changes, or look through the Subversion logs for all the details.
|
|||
with any object literal that decodes to a list of pairs.
|
||||
(Contributed by Raymond Hettinger; :issue:`5381`.)
|
||||
|
||||
* The :mod:`mailbox` module's :class:`Maildir` class now records the
|
||||
* The :mod:`mailbox` module's :class:`~mailbox.Maildir` class now records the
|
||||
timestamp on the directories it reads, and only re-reads them if the
|
||||
modification time has subsequently changed. This improves
|
||||
performance by avoiding unneeded directory scans. (Fixed by
|
||||
|
@ -1432,7 +1472,7 @@ changes, or look through the Subversion logs for all the details.
|
|||
* The :mod:`signal` module no longer re-installs the signal handler
|
||||
unless this is truly necessary, which fixes a bug that could make it
|
||||
impossible to catch the EINTR signal robustly. (Fixed by
|
||||
Charles-François Natali; :issue:`8354`.)
|
||||
Charles-Francois Natali; :issue:`8354`.)
|
||||
|
||||
* New functions: in the :mod:`site` module, three new functions
|
||||
return various site- and user-specific paths.
|
||||
|
@ -1466,10 +1506,10 @@ changes, or look through the Subversion logs for all the details.
|
|||
defaults to False; if overridden to be True,
|
||||
new request connections will have the TCP_NODELAY option set to
|
||||
prevent buffering many small sends into a single TCP packet.
|
||||
The :attr:`~SocketServer.TCPServer.timeout` class attribute can hold
|
||||
The :attr:`~SocketServer.BaseServer.timeout` class attribute can hold
|
||||
a timeout in seconds that will be applied to the request socket; if
|
||||
no request is received within that time, :meth:`handle_timeout`
|
||||
will be called and :meth:`handle_request` will return.
|
||||
no request is received within that time, :meth:`~SocketServer.BaseServer.handle_timeout`
|
||||
will be called and :meth:`~SocketServer.BaseServer.handle_request` will return.
|
||||
(Contributed by Kristján Valur Jónsson; :issue:`6192` and :issue:`6267`.)
|
||||
|
||||
* Updated module: the :mod:`sqlite3` module has been updated to
|
||||
|
@ -1479,7 +1519,7 @@ changes, or look through the Subversion logs for all the details.
|
|||
and then call :meth:`~sqlite3.Connection.load_extension` to load a particular shared library.
|
||||
(Updated by Gerhard Häring.)
|
||||
|
||||
* The :mod:`ssl` module's :class:`ssl.SSLSocket` objects now support the
|
||||
* The :mod:`ssl` module's :class:`~ssl.SSLSocket` objects now support the
|
||||
buffer API, which fixed a test suite failure (fix by Antoine Pitrou;
|
||||
:issue:`7133`) and automatically set
|
||||
OpenSSL's :c:macro:`SSL_MODE_AUTO_RETRY`, which will prevent an error
|
||||
|
@ -1535,7 +1575,7 @@ changes, or look through the Subversion logs for all the details.
|
|||
on receiving an :const:`EINTR` signal. (Reported by several people; final
|
||||
patch by Gregory P. Smith in :issue:`1068268`.)
|
||||
|
||||
* New function: :func:`~symtable.is_declared_global` in the :mod:`symtable` module
|
||||
* New function: :func:`~symtable.Symbol.is_declared_global` in the :mod:`symtable` module
|
||||
returns true for variables that are explicitly declared to be global,
|
||||
false for ones that are implicitly global.
|
||||
(Contributed by Jeremy Hylton.)
|
||||
|
@ -1716,7 +1756,7 @@ Some of the functions in the module are:
|
|||
Makefile and the :file:`pyconfig.h` file.
|
||||
* :func:`~sysconfig.get_config_vars` returns a dictionary containing
|
||||
all of the configuration variables.
|
||||
* :func:`~sysconfig.getpath` returns the configured path for
|
||||
* :func:`~sysconfig.get_path` returns the configured path for
|
||||
a particular type of module: the standard library,
|
||||
site-specific modules, platform-specific modules, etc.
|
||||
* :func:`~sysconfig.is_python_build` returns true if you're running a
|
||||
|
@ -1778,7 +1818,7 @@ any importable test files named ``test*.py``::
|
|||
Consult the :mod:`unittest` module documentation for more details.
|
||||
(Developed in :issue:`6001`.)
|
||||
|
||||
The :func:`main` function supports some other new options:
|
||||
The :func:`~unittest.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,
|
||||
|
@ -1796,7 +1836,7 @@ The :func:`main` function supports some other new options:
|
|||
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
|
||||
:func:`removeHandler` decorator that can be used to mark tests that
|
||||
:func:`~unittest.removeHandler` decorator that can be used to mark tests that
|
||||
should have the control-C handling disabled.
|
||||
|
||||
* :option:`-f` or :option:`--failfast` makes
|
||||
|
@ -1923,7 +1963,7 @@ GvR worked on merging them into Python's version of :mod:`unittest`.
|
|||
|
||||
:func:`unittest.main` now takes an optional ``exit`` argument. If
|
||||
False, :func:`~unittest.main` doesn't call :func:`sys.exit`, allowing
|
||||
:func:`main` to be used from the interactive interpreter.
|
||||
:func:`~unittest.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
|
||||
|
@ -2120,7 +2160,7 @@ Changes to Python's build process and to the C API include:
|
|||
:c:macro:`Py_ISSPACE`,
|
||||
:c:macro:`Py_ISUPPER`,
|
||||
:c:macro:`Py_ISXDIGIT`,
|
||||
and :c:macro:`Py_TOLOWER`, :c:macro:`Py_TOUPPER`.
|
||||
:c:macro:`Py_TOLOWER`, and :c:macro:`Py_TOUPPER`.
|
||||
All of these functions are analogous to the C
|
||||
standard macros for classifying characters, but ignore the current
|
||||
locale setting, because in
|
||||
|
@ -2266,11 +2306,11 @@ Port-Specific Changes: Windows
|
|||
(Contributed by David Cournapeau; :issue:`4365`.)
|
||||
|
||||
* The :mod:`_winreg` module for accessing the registry now implements
|
||||
the :func:`CreateKeyEx` and :func:`DeleteKeyEx` functions, extended
|
||||
versions of previously-supported functions that take several extra
|
||||
arguments. The :func:`DisableReflectionKey`,
|
||||
:func:`EnableReflectionKey`, and :func:`QueryReflectionKey` were also
|
||||
tested and documented.
|
||||
the :func:`~_winreg.CreateKeyEx` and :func:`~_winreg.DeleteKeyEx`
|
||||
functions, extended versions of previously-supported functions that
|
||||
take several extra arguments. The :func:`~_winreg.DisableReflectionKey`,
|
||||
:func:`~_winreg.EnableReflectionKey`, and :func:`~_winreg.QueryReflectionKey`
|
||||
were also tested and documented.
|
||||
(Implemented by Brian Curtin: :issue:`7347`.)
|
||||
|
||||
* The new :c:func:`_beginthreadex` API is used to start threads, and
|
||||
|
@ -2329,7 +2369,7 @@ Other Changes and Fixes
|
|||
attributes of the resulting code objects are overwritten when the
|
||||
original filename is obsolete. This can happen if the file has been
|
||||
renamed, moved, or is accessed through different paths. (Patch by
|
||||
Žiga Seilnacht and Jean-Paul Calderone; :issue:`1180193`.)
|
||||
Ziga Seilnacht and Jean-Paul Calderone; :issue:`1180193`.)
|
||||
|
||||
* The :file:`regrtest.py` script now takes a :option:`--randseed=`
|
||||
switch that takes an integer that will be used as the random seed
|
||||
|
@ -2387,20 +2427,20 @@ that may require changes to your code:
|
|||
|
||||
In the standard library:
|
||||
|
||||
* Operations with :class:`datetime` instances that resulted in a year
|
||||
* Operations with :class:`~datetime.datetime` instances that resulted in a year
|
||||
falling outside the supported range didn't always raise
|
||||
:exc:`OverflowError`. Such errors are now checked more carefully
|
||||
and will now raise the exception. (Reported by Mark Leander, patch
|
||||
by Anand B. Pillai and Alexander Belopolsky; :issue:`7150`.)
|
||||
|
||||
* When using :class:`Decimal` instances with a string's
|
||||
* When using :class:`~decimal.Decimal` instances with a string's
|
||||
:meth:`format` method, the default alignment was previously
|
||||
left-alignment. This has been changed to right-alignment, which might
|
||||
change the output of your programs.
|
||||
(Changed by Mark Dickinson; :issue:`6857`.)
|
||||
|
||||
Comparisons involving a signaling NaN value (or ``sNAN``) now signal
|
||||
:const:`InvalidOperation` instead of silently returning a true or
|
||||
:const:`~decimal.InvalidOperation` instead of silently returning a true or
|
||||
false value depending on the comparison operator. Quiet NaN values
|
||||
(or ``NaN``) are now hashable. (Fixed by Mark Dickinson;
|
||||
:issue:`7279`.)
|
||||
|
@ -2411,7 +2451,7 @@ In the standard library:
|
|||
or comment (which looks like `<!-- comment -->`).
|
||||
(Patch by Neil Muller; :issue:`2746`.)
|
||||
|
||||
* The :meth:`readline` method of :class:`StringIO` objects now does
|
||||
* The :meth:`~StringIO.StringIO.readline` method of :class:`~StringIO.StringIO` objects now does
|
||||
nothing when a negative length is requested, as other file-like
|
||||
objects do. (:issue:`7348`).
|
||||
|
||||
|
@ -2470,6 +2510,54 @@ For applications that embed Python:
|
|||
.. ======================================================================
|
||||
|
||||
|
||||
.. _py27-maintenance-enhancements:
|
||||
|
||||
New Features Added to Python 2.7 Maintenance Releases
|
||||
=====================================================
|
||||
|
||||
New features may be added to Python 2.7 maintenance releases when the
|
||||
situation genuinely calls for it. Any such additions must go through
|
||||
the Python Enhancement Proposal process, and make a compelling case for why
|
||||
they can't be adequately addressed by either adding the new feature solely to
|
||||
Python 3, or else by publishing it on the Python Package Index.
|
||||
|
||||
In addition to the specific proposals listed below, there is a general
|
||||
exemption allowing new ``-3`` warnings to be added in any Python 2.7
|
||||
maintenance release.
|
||||
|
||||
|
||||
PEP 434: IDLE Enhancement Exception for All Branches
|
||||
----------------------------------------------------
|
||||
|
||||
:pep:`434` describes a general exemption for changes made to the IDLE
|
||||
development environment shipped along with Python. This exemption makes it
|
||||
possible for the IDLE developers to provide a more consistent user
|
||||
experience across all supported versions of Python 2 and 3.
|
||||
|
||||
For details of any IDLE changes, refer to the NEWS file for the specific
|
||||
release.
|
||||
|
||||
|
||||
PEP 466: Network Security Enhancements for Python 2.7
|
||||
-----------------------------------------------------
|
||||
|
||||
:pep:`466` describes a number of network security enhancement proposals
|
||||
that have been approved for inclusion in Python 2.7 maintenance releases,
|
||||
with the first of those changes appearing in the Python 2.7.7 release.
|
||||
|
||||
:pep:`466` related features added in Python 2.7.7:
|
||||
|
||||
* :func:`hmac.compare_digest` was added to make a timing attack resistant
|
||||
comparison operation broadly available to Python 2 applications
|
||||
(backported by Alex Gaynor in :issue:`21306`)
|
||||
|
||||
* the version of OpenSSL linked with the prebuilt Windows installers
|
||||
published on python.org was updated to 1.0.1g (contributed by
|
||||
Zachary Ware in :issue:`21462`)
|
||||
|
||||
|
||||
.. ======================================================================
|
||||
|
||||
.. _acks27:
|
||||
|
||||
Acknowledgements
|
||||
|
|
Loading…
Reference in New Issue