Issue #21569: sync Python 2.7 What's New with 2.7 version

This commit is contained in:
Nick Coghlan 2014-06-07 23:43:00 +10:00
parent 1462786f00
commit 024b2f52bf
1 changed files with 195 additions and 107 deletions

View File

@ -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