[Python-checkins] cpython (merge 3.4 -> default): Merge issue #21569 from 3.4
nick.coghlan
python-checkins at python.org
Sat Jun 7 16:00:34 CEST 2014
http://hg.python.org/cpython/rev/b167df2912d6
changeset: 91060:b167df2912d6
parent: 91057:7c120e77d6f7
parent: 91059:d23cea976f46
user: Nick Coghlan <ncoghlan at gmail.com>
date: Sun Jun 08 00:00:13 2014 +1000
summary:
Merge issue #21569 from 3.4
files:
Doc/whatsnew/2.7.rst | 318 +++++++++++++++++++-----------
1 files changed, 203 insertions(+), 115 deletions(-)
diff --git a/Doc/whatsnew/2.7.rst b/Doc/whatsnew/2.7.rst
--- a/Doc/whatsnew/2.7.rst
+++ b/Doc/whatsnew/2.7.rst
@@ -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 @@
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.
-
-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:
-
-* 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.
-
-* 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`.)
-
- 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` (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')``.
+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.
+
+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.
+
+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`.
+
+Some key consequences of the long-term significance of 2.7 are:
+
+* 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).
+
+* 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.
+
+* 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 @@
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 @@
* :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 @@
.. seealso::
- `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>`__
+ :mod:`argparse` documentation
+ The documentation page of the argparse module.
+
+ :ref:`argparse-from-optparse`
Part of the Python documentation, describing how to convert
code that uses :mod:`optparse`.
@@ -402,8 +447,6 @@
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 @@
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 @@
'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 @@
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 @@
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.
-
-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`.
+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:`~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 @@
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 @@
``{}`` 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 @@
``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 @@
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 @@
: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 @@
``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 @@
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 @@
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 @@
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 @@
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 @@
* 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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
: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 @@
: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 @@
(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 @@
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 @@
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 @@
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 @@
.. ======================================================================
+.. _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
--
Repository URL: http://hg.python.org/cpython
More information about the Python-checkins
mailing list