3082 lines
119 KiB
ReStructuredText
3082 lines
119 KiB
ReStructuredText
****************************
|
|
What's New in Python 2.6
|
|
****************************
|
|
|
|
.. XXX add trademark info for Apple, Microsoft, SourceForge.
|
|
|
|
:Author: A.M. Kuchling
|
|
:Release: |release|
|
|
:Date: |today|
|
|
|
|
.. $Id: whatsnew26.tex 55746 2007-06-02 18:33:53Z neal.norwitz $
|
|
Rules for maintenance:
|
|
|
|
* Anyone can add text to this document. Do not spend very much time
|
|
on the wording of your changes, because your text will probably
|
|
get rewritten to some degree.
|
|
|
|
* The maintainer will go through Misc/NEWS periodically and add
|
|
changes; it's therefore more important to add your changes to
|
|
Misc/NEWS than to this file.
|
|
|
|
* This is not a complete list of every single change; completeness
|
|
is the purpose of Misc/NEWS. Some changes I consider too small
|
|
or esoteric to include. If such a change is added to the text,
|
|
I'll just remove it. (This is another reason you shouldn't spend
|
|
too much time on writing your addition.)
|
|
|
|
* If you want to draw your new text to the attention of the
|
|
maintainer, add 'XXX' to the beginning of the paragraph or
|
|
section.
|
|
|
|
* It's OK to just add a fragmentary note about a change. For
|
|
example: "XXX Describe the transmogrify() function added to the
|
|
socket module." The maintainer will research the change and
|
|
write the necessary text.
|
|
|
|
* You can comment out your additions if you like, but it's not
|
|
necessary (especially when a final release is some months away).
|
|
|
|
* Credit the author of a patch or bugfix. Just the name is
|
|
sufficient; the e-mail address isn't necessary.
|
|
|
|
* It's helpful to add the bug/patch number in a parenthetical comment.
|
|
|
|
XXX Describe the transmogrify() function added to the socket
|
|
module.
|
|
(Contributed by P.Y. Developer; :issue:`12345`.)
|
|
|
|
This saves the maintainer some effort going through the SVN logs
|
|
when researching a change.
|
|
|
|
This article explains the new features in Python 2.6. The release
|
|
schedule is described in :pep:`361`; currently the final release is
|
|
scheduled for October 1 2008.
|
|
|
|
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.6. If
|
|
you want to understand the rationale for the design and
|
|
implementation, refer to the PEP for a particular new feature.
|
|
Whenever possible, "What's New in Python" links to the bug/patch item
|
|
for each change.
|
|
|
|
.. Compare with previous release in 2 - 3 sentences here.
|
|
add hyperlink when the documentation becomes available online.
|
|
|
|
.. ========================================================================
|
|
.. Large, PEP-level features and changes should be described here.
|
|
.. Should there be a new section here for 3k migration?
|
|
.. Or perhaps a more general section describing module changes/deprecation?
|
|
.. ========================================================================
|
|
|
|
Python 3.0
|
|
================
|
|
|
|
The development cycle for Python 2.6 also saw the release of the first
|
|
alphas of Python 3.0, and the development of 3.0 has influenced
|
|
a number of features in 2.6.
|
|
|
|
Python 3.0 is a far-ranging redesign of Python that breaks
|
|
compatibility with the 2.x series. This means that existing Python
|
|
code will need a certain amount of conversion in order to run on
|
|
Python 3.0. However, not all the changes in 3.0 necessarily break
|
|
compatibility. In cases where new features won't cause existing code
|
|
to break, they've been backported to 2.6 and are described in this
|
|
document in the appropriate place. Some of the 3.0-derived features
|
|
are:
|
|
|
|
* A :meth:`__complex__` method for converting objects to a complex number.
|
|
* Alternate syntax for catching exceptions: ``except TypeError as exc``.
|
|
* The addition of :func:`functools.reduce` as a synonym for the built-in
|
|
:func:`reduce` function.
|
|
|
|
A new command-line switch, :option:`-3`, enables warnings
|
|
about features that will be removed in Python 3.0. You can run code
|
|
with this switch to see how much work will be necessary to port
|
|
code to 3.0. The value of this switch is available
|
|
to Python code as the boolean variable :data:`sys.py3kwarning`,
|
|
and to C extension code as :cdata:`Py_Py3kWarningFlag`.
|
|
|
|
Python 3.0 adds several new built-in functions and change the
|
|
semantics of some existing built-ins. Entirely new functions such as
|
|
:func:`bin` have simply been added to Python 2.6, but existing
|
|
built-ins haven't been changed; instead, the :mod:`future_builtins`
|
|
module has versions with the new 3.0 semantics. Code written to be
|
|
compatible with 3.0 can do ``from future_builtins import hex, map``
|
|
as necessary.
|
|
|
|
.. seealso::
|
|
|
|
The 3xxx series of PEPs, which describes the development process for
|
|
Python 3.0 and various features that have been accepted, rejected,
|
|
or are still under consideration.
|
|
|
|
|
|
Development Changes
|
|
==================================================
|
|
|
|
While 2.6 was being developed, the Python development process
|
|
underwent two significant changes: the developer group
|
|
switched from SourceForge's issue tracker to a customized
|
|
Roundup installation, and the documentation was converted from
|
|
LaTeX to reStructuredText.
|
|
|
|
|
|
New Issue Tracker: Roundup
|
|
--------------------------------------------------
|
|
|
|
For a long time, the Python developers have been growing increasingly
|
|
annoyed by SourceForge's bug tracker. SourceForge's hosted solution
|
|
doesn't permit much customization; for example, it wasn't possible to
|
|
customize the life cycle of issues.
|
|
|
|
The infrastructure committee of the Python Software Foundation
|
|
therefore posted a call for issue trackers, asking volunteers to set
|
|
up different products and import some of the bugs and patches from
|
|
SourceForge. Four different trackers were examined: Atlassian's `Jira
|
|
<http://www.atlassian.com/software/jira/>`__,
|
|
`Launchpad <http://www.launchpad.net>`__,
|
|
`Roundup <http://roundup.sourceforge.net/>`__, and
|
|
`Trac <http://trac.edgewall.org/>`__.
|
|
The committee eventually settled on Jira
|
|
and Roundup as the two candidates. Jira is a commercial product that
|
|
offers a no-cost hosted instance to free-software projects; Roundup
|
|
is an open-source project that requires volunteers
|
|
to administer it and a server to host it.
|
|
|
|
After posting a call for volunteers, a new Roundup installation was
|
|
set up at http://bugs.python.org. One installation of Roundup can
|
|
host multiple trackers, and this server now also hosts issue trackers
|
|
for Jython and for the Python web site. It will surely find
|
|
other uses in the future. Where possible,
|
|
this edition of "What's New in Python" links to the bug/patch
|
|
item for each change.
|
|
|
|
Hosting is kindly provided by
|
|
`Upfront Systems <http://www.upfrontsystems.co.za/>`__
|
|
of Stellenbosch, South Africa. Martin von Loewis put a
|
|
lot of effort into importing existing bugs and patches from
|
|
SourceForge; his scripts for this import operation are at
|
|
http://svn.python.org/view/tracker/importer/.
|
|
|
|
.. seealso::
|
|
|
|
http://bugs.python.org
|
|
The Python bug tracker.
|
|
|
|
http://bugs.jython.org:
|
|
The Jython bug tracker.
|
|
|
|
http://roundup.sourceforge.net/
|
|
Roundup downloads and documentation.
|
|
|
|
|
|
New Documentation Format: reStructuredText Using Sphinx
|
|
-----------------------------------------------------------
|
|
|
|
Since the Python project's inception around 1989, the documentation
|
|
had been written using LaTeX. At that time, most documentation was
|
|
printed out for later study, not viewed online. LaTeX was widely used
|
|
because it provided attractive printed output while remaining
|
|
straightforward to write, once the basic rules of the markup have been
|
|
learned.
|
|
|
|
LaTeX is still used today for writing technical publications destined
|
|
for printing, but the landscape for programming tools has shifted. We
|
|
no longer print out reams of documentation; instead, we browse through
|
|
it online and HTML has become the most important format to support.
|
|
Unfortunately, converting LaTeX to HTML is fairly complicated, and
|
|
Fred L. Drake Jr., the Python documentation editor for many years,
|
|
spent a lot of time wrestling the conversion process into shape.
|
|
Occasionally people would suggest converting the documentation into
|
|
SGML or, later, XML, but performing a good conversion is a major task
|
|
and no one pursued the task to completion.
|
|
|
|
During the 2.6 development cycle, Georg Brandl put a substantial
|
|
effort into building a new toolchain for processing the documentation.
|
|
The resulting package is called Sphinx, and is available from
|
|
http://sphinx.pocoo.org/. The input format is reStructuredText, a
|
|
markup commonly used in the Python community that supports custom
|
|
extensions and directives. Sphinx concentrates on HTML output,
|
|
producing attractively styled and modern HTML, though printed output
|
|
is still supported through conversion to LaTeX. Sphinx is a
|
|
standalone package that can be used in documenting other projects.
|
|
|
|
.. seealso::
|
|
|
|
:ref:`documenting-index`
|
|
Describes how to write for Python's documentation.
|
|
|
|
`Sphinx <http://sphinx.pocoo.org/>`__
|
|
Documentation and code for the Sphinx toolchain.
|
|
|
|
`Docutils <http://docutils.sf.net>`__
|
|
The underlying reStructuredText parser and toolset.
|
|
|
|
|
|
PEP 343: The 'with' statement
|
|
=============================
|
|
|
|
The previous version, Python 2.5, added the ':keyword:`with`'
|
|
statement an optional feature, to be enabled by a ``from __future__
|
|
import with_statement`` directive. In 2.6 the statement no longer needs to
|
|
be specially enabled; this means that :keyword:`with` is now always a
|
|
keyword. The rest of this section is a copy of the corresponding
|
|
section from "What's New in Python 2.5" document; if you read
|
|
it back when Python 2.5 came out, you can skip the rest of this
|
|
section.
|
|
|
|
The ':keyword:`with`' statement clarifies code that previously would use
|
|
``try...finally`` blocks to ensure that clean-up code is executed. In this
|
|
section, I'll discuss the statement as it will commonly be used. In the next
|
|
section, I'll examine the implementation details and show how to write objects
|
|
for use with this statement.
|
|
|
|
The ':keyword:`with`' statement is a new control-flow structure whose basic
|
|
structure is::
|
|
|
|
with expression [as variable]:
|
|
with-block
|
|
|
|
The expression is evaluated, and it should result in an object that supports the
|
|
context management protocol (that is, has :meth:`__enter__` and :meth:`__exit__`
|
|
methods.
|
|
|
|
The object's :meth:`__enter__` is called before *with-block* is executed and
|
|
therefore can run set-up code. It also may return a value that is bound to the
|
|
name *variable*, if given. (Note carefully that *variable* is *not* assigned
|
|
the result of *expression*.)
|
|
|
|
After execution of the *with-block* is finished, the object's :meth:`__exit__`
|
|
method is called, even if the block raised an exception, and can therefore run
|
|
clean-up code.
|
|
|
|
Some standard Python objects now support the context management protocol and can
|
|
be used with the ':keyword:`with`' statement. File objects are one example::
|
|
|
|
with open('/etc/passwd', 'r') as f:
|
|
for line in f:
|
|
print line
|
|
... more processing code ...
|
|
|
|
After this statement has executed, the file object in *f* will have been
|
|
automatically closed, even if the :keyword:`for` loop raised an exception part-
|
|
way through the block.
|
|
|
|
.. note::
|
|
|
|
In this case, *f* is the same object created by :func:`open`, because
|
|
:meth:`file.__enter__` returns *self*.
|
|
|
|
The :mod:`threading` module's locks and condition variables also support the
|
|
':keyword:`with`' statement::
|
|
|
|
lock = threading.Lock()
|
|
with lock:
|
|
# Critical section of code
|
|
...
|
|
|
|
The lock is acquired before the block is executed and always released once the
|
|
block is complete.
|
|
|
|
The new :func:`localcontext` function in the :mod:`decimal` module makes it easy
|
|
to save and restore the current decimal context, which encapsulates the desired
|
|
precision and rounding characteristics for computations::
|
|
|
|
from decimal import Decimal, Context, localcontext
|
|
|
|
# Displays with default precision of 28 digits
|
|
v = Decimal('578')
|
|
print v.sqrt()
|
|
|
|
with localcontext(Context(prec=16)):
|
|
# All code in this block uses a precision of 16 digits.
|
|
# The original context is restored on exiting the block.
|
|
print v.sqrt()
|
|
|
|
|
|
.. _new-26-context-managers:
|
|
|
|
Writing Context Managers
|
|
------------------------
|
|
|
|
Under the hood, the ':keyword:`with`' statement is fairly complicated. Most
|
|
people will only use ':keyword:`with`' in company with existing objects and
|
|
don't need to know these details, so you can skip the rest of this section if
|
|
you like. Authors of new objects will need to understand the details of the
|
|
underlying implementation and should keep reading.
|
|
|
|
A high-level explanation of the context management protocol is:
|
|
|
|
* The expression is evaluated and should result in an object called a "context
|
|
manager". The context manager must have :meth:`__enter__` and :meth:`__exit__`
|
|
methods.
|
|
|
|
* The context manager's :meth:`__enter__` method is called. The value returned
|
|
is assigned to *VAR*. If no ``as VAR`` clause is present, the value is simply
|
|
discarded.
|
|
|
|
* The code in *BLOCK* is executed.
|
|
|
|
* If *BLOCK* raises an exception, the :meth:`__exit__(type, value, traceback)`
|
|
is called with the exception details, the same values returned by
|
|
:func:`sys.exc_info`. The method's return value controls whether the exception
|
|
is re-raised: any false value re-raises the exception, and ``True`` will result
|
|
in suppressing it. You'll only rarely want to suppress the exception, because
|
|
if you do the author of the code containing the ':keyword:`with`' statement will
|
|
never realize anything went wrong.
|
|
|
|
* If *BLOCK* didn't raise an exception, the :meth:`__exit__` method is still
|
|
called, but *type*, *value*, and *traceback* are all ``None``.
|
|
|
|
Let's think through an example. I won't present detailed code but will only
|
|
sketch the methods necessary for a database that supports transactions.
|
|
|
|
(For people unfamiliar with database terminology: a set of changes to the
|
|
database are grouped into a transaction. Transactions can be either committed,
|
|
meaning that all the changes are written into the database, or rolled back,
|
|
meaning that the changes are all discarded and the database is unchanged. See
|
|
any database textbook for more information.)
|
|
|
|
Let's assume there's an object representing a database connection. Our goal will
|
|
be to let the user write code like this::
|
|
|
|
db_connection = DatabaseConnection()
|
|
with db_connection as cursor:
|
|
cursor.execute('insert into ...')
|
|
cursor.execute('delete from ...')
|
|
# ... more operations ...
|
|
|
|
The transaction should be committed if the code in the block runs flawlessly or
|
|
rolled back if there's an exception. Here's the basic interface for
|
|
:class:`DatabaseConnection` that I'll assume::
|
|
|
|
class DatabaseConnection:
|
|
# Database interface
|
|
def cursor(self):
|
|
"Returns a cursor object and starts a new transaction"
|
|
def commit(self):
|
|
"Commits current transaction"
|
|
def rollback(self):
|
|
"Rolls back current transaction"
|
|
|
|
The :meth:`__enter__` method is pretty easy, having only to start a new
|
|
transaction. For this application the resulting cursor object would be a useful
|
|
result, so the method will return it. The user can then add ``as cursor`` to
|
|
their ':keyword:`with`' statement to bind the cursor to a variable name. ::
|
|
|
|
class DatabaseConnection:
|
|
...
|
|
def __enter__(self):
|
|
# Code to start a new transaction
|
|
cursor = self.cursor()
|
|
return cursor
|
|
|
|
The :meth:`__exit__` method is the most complicated because it's where most of
|
|
the work has to be done. The method has to check if an exception occurred. If
|
|
there was no exception, the transaction is committed. The transaction is rolled
|
|
back if there was an exception.
|
|
|
|
In the code below, execution will just fall off the end of the function,
|
|
returning the default value of ``None``. ``None`` is false, so the exception
|
|
will be re-raised automatically. If you wished, you could be more explicit and
|
|
add a :keyword:`return` statement at the marked location. ::
|
|
|
|
class DatabaseConnection:
|
|
...
|
|
def __exit__(self, type, value, tb):
|
|
if tb is None:
|
|
# No exception, so commit
|
|
self.commit()
|
|
else:
|
|
# Exception occurred, so rollback.
|
|
self.rollback()
|
|
# return False
|
|
|
|
|
|
.. _module-contextlib:
|
|
|
|
The contextlib module
|
|
---------------------
|
|
|
|
The new :mod:`contextlib` module provides some functions and a decorator that
|
|
are useful for writing objects for use with the ':keyword:`with`' statement.
|
|
|
|
The decorator is called :func:`contextmanager`, and lets you write a single
|
|
generator function instead of defining a new class. The generator should yield
|
|
exactly one value. The code up to the :keyword:`yield` will be executed as the
|
|
:meth:`__enter__` method, and the value yielded will be the method's return
|
|
value that will get bound to the variable in the ':keyword:`with`' statement's
|
|
:keyword:`as` clause, if any. The code after the :keyword:`yield` will be
|
|
executed in the :meth:`__exit__` method. Any exception raised in the block will
|
|
be raised by the :keyword:`yield` statement.
|
|
|
|
Our database example from the previous section could be written using this
|
|
decorator as::
|
|
|
|
from contextlib import contextmanager
|
|
|
|
@contextmanager
|
|
def db_transaction(connection):
|
|
cursor = connection.cursor()
|
|
try:
|
|
yield cursor
|
|
except:
|
|
connection.rollback()
|
|
raise
|
|
else:
|
|
connection.commit()
|
|
|
|
db = DatabaseConnection()
|
|
with db_transaction(db) as cursor:
|
|
...
|
|
|
|
The :mod:`contextlib` module also has a :func:`nested(mgr1, mgr2, ...)` function
|
|
that combines a number of context managers so you don't need to write nested
|
|
':keyword:`with`' statements. In this example, the single ':keyword:`with`'
|
|
statement both starts a database transaction and acquires a thread lock::
|
|
|
|
lock = threading.Lock()
|
|
with nested (db_transaction(db), lock) as (cursor, locked):
|
|
...
|
|
|
|
Finally, the :func:`closing(object)` function returns *object* so that it can be
|
|
bound to a variable, and calls ``object.close`` at the end of the block. ::
|
|
|
|
import urllib, sys
|
|
from contextlib import closing
|
|
|
|
with closing(urllib.urlopen('http://www.yahoo.com')) as f:
|
|
for line in f:
|
|
sys.stdout.write(line)
|
|
|
|
|
|
.. seealso::
|
|
|
|
:pep:`343` - The "with" statement
|
|
PEP written by Guido van Rossum and Nick Coghlan; implemented by Mike Bland,
|
|
Guido van Rossum, and Neal Norwitz. The PEP shows the code generated for a
|
|
':keyword:`with`' statement, which can be helpful in learning how the statement
|
|
works.
|
|
|
|
The documentation for the :mod:`contextlib` module.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-0366:
|
|
|
|
PEP 366: Explicit Relative Imports From a Main Module
|
|
============================================================
|
|
|
|
Python's :option:`-m` switch allows running a module as a script.
|
|
When you ran a module that was located inside a package, relative
|
|
imports didn't work correctly.
|
|
|
|
The fix in Python 2.6 adds a :attr:`__package__` attribute to modules.
|
|
When present, relative imports will be relative to the value of this
|
|
attribute instead of the :attr:`__name__` attribute. PEP 302-style
|
|
importers can then set :attr:`__package__`. The :mod:`runpy` module
|
|
that implements the :option:`-m` switch now does this, so relative imports
|
|
can now be used in scripts running from inside a package.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-0370:
|
|
|
|
PEP 370: Per-user ``site-packages`` Directory
|
|
=====================================================
|
|
|
|
When you run Python, the module search path ``sys.modules`` usually
|
|
includes a directory whose path ends in ``"site-packages"``. This
|
|
directory is intended to hold locally-installed packages available to
|
|
all users on a machine or using a particular site installation.
|
|
|
|
Python 2.6 introduces a convention for user-specific site directories.
|
|
The directory varies depending on the platform:
|
|
|
|
* Unix and MacOS: :file:`~/.local/`
|
|
* Windows: :file:`%APPDATA%/Python`
|
|
|
|
Within this directory, there will be version-specific subdirectories,
|
|
such as :file:`lib/python2.6/site-packages` on Unix/MacOS and
|
|
:file:`Python26/site-packages` on Windows.
|
|
|
|
If you don't like the default directory, it can be overridden by an
|
|
environment variable. :envvar:`PYTHONUSERBASE` sets the root
|
|
directory used for all Python versions supporting this feature. On
|
|
Windows, the directory for application-specific data can be changed by
|
|
setting the :envvar:`APPDATA` environment variable. You can also
|
|
modify the :file:`site.py` file for your Python installation.
|
|
|
|
The feature can be disabled entirely by running Python with the
|
|
:option:`-s` option or setting the :envvar:`PYTHONNOUSERSITE`
|
|
environment variable.
|
|
|
|
.. seealso::
|
|
|
|
:pep:`370` - Per-user ``site-packages`` Directory
|
|
PEP written and implemented by Christian Heimes.
|
|
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-0371:
|
|
|
|
PEP 371: The ``multiprocessing`` Package
|
|
=====================================================
|
|
|
|
The new :mod:`multiprocessing` package lets Python programs create new
|
|
processes that will perform a computation and return a result to the
|
|
parent. The parent and child processes can communicate using queues
|
|
and pipes, synchronize their operations using locks and semaphores,
|
|
and can share simple arrays of data.
|
|
|
|
The :mod:`multiprocessing` module started out as an exact emulation of
|
|
the :mod:`threading` module using processes instead of threads. That
|
|
goal was discarded along the path to Python 2.6, but the general
|
|
approach of the module is still similar. The fundamental class
|
|
is the :class:`Process`, which is passed a callable object and
|
|
a collection of arguments. The :meth:`start` method
|
|
sets the callable running in a subprocess, after which you can call
|
|
the :meth:`is_alive` method to check whether the subprocess is still running
|
|
and the :meth:`join` method to wait for the process to exit.
|
|
|
|
Here's a simple example where the subprocess will calculate a
|
|
factorial. The function doing the calculation is a bit strange; it's
|
|
written to take significantly longer when the input argument is a
|
|
multiple of 4.
|
|
|
|
::
|
|
|
|
import time
|
|
from multiprocessing import Process, Queue
|
|
|
|
|
|
def factorial(queue, N):
|
|
"Compute a factorial."
|
|
# If N is a multiple of 4, this function will take much longer.
|
|
if (N % 4) == 0:
|
|
time.sleep(.05 * N/4)
|
|
|
|
# Calculate the result
|
|
fact = 1L
|
|
for i in range(1, N+1):
|
|
fact = fact * i
|
|
|
|
# Put the result on the queue
|
|
queue.put(fact)
|
|
|
|
if __name__ == '__main__':
|
|
queue = Queue()
|
|
|
|
N = 5
|
|
|
|
p = Process(target=factorial, args=(queue, N))
|
|
p.start()
|
|
p.join()
|
|
|
|
result = queue.get()
|
|
print 'Factorial', N, '=', result
|
|
|
|
A :class:`Queue` object is created and stored as a global. The child
|
|
process will use the value of the variable when the child was created;
|
|
because it's a :class:`Queue`, parent and child can use the object to
|
|
communicate. (If the parent were to change the value of the global
|
|
variable, the child's value would be unaffected, and vice versa.)
|
|
|
|
Two other classes, :class:`Pool` and :class:`Manager`, provide
|
|
higher-level interfaces. :class:`Pool` will create a fixed number of
|
|
worker processes, and requests can then be distributed to the workers
|
|
by calling :meth:`apply` or `apply_async`, adding a single request,
|
|
and :meth:`map` or :meth:`map_async` to distribute a number of
|
|
requests. The following code uses a :class:`Pool` to spread requests
|
|
across 5 worker processes, receiving a list of results back.
|
|
|
|
::
|
|
|
|
from multiprocessing import Pool
|
|
|
|
p = Pool(5)
|
|
result = p.map(factorial, range(1, 1000, 10))
|
|
for v in result:
|
|
print v
|
|
|
|
This produces the following output::
|
|
|
|
1
|
|
39916800
|
|
51090942171709440000
|
|
8222838654177922817725562880000000
|
|
33452526613163807108170062053440751665152000000000
|
|
...
|
|
|
|
The :class:`Manager` class creates a separate server process that can
|
|
hold master copies of Python data structures. Other processes can
|
|
then access and modify these data structures by using proxy objects.
|
|
The following example creates a shared dictionary by calling the
|
|
:meth:`dict` method; the worker processes then insert values into the
|
|
dictionary. (No locking is done automatically, which doesn't matter
|
|
in this example. :class:`Manager`'s methods also include
|
|
:meth:`Lock`, :meth:`RLock`, and :meth:`Semaphore` to create shared locks.
|
|
|
|
::
|
|
|
|
import time
|
|
from multiprocessing import Pool, Manager
|
|
|
|
def factorial(N, dictionary):
|
|
"Compute a factorial."
|
|
# Calculate the result
|
|
fact = 1L
|
|
for i in range(1, N+1):
|
|
fact = fact * i
|
|
|
|
# Store result in dictionary
|
|
dictionary[N] = fact
|
|
|
|
if __name__ == '__main__':
|
|
p = Pool(5)
|
|
mgr = Manager()
|
|
d = mgr.dict() # Create shared dictionary
|
|
|
|
# Run tasks using the pool
|
|
for N in range(1, 1000, 10):
|
|
p.apply_async(factorial, (N, d))
|
|
|
|
# Mark pool as closed -- no more tasks can be added.
|
|
p.close()
|
|
|
|
# Wait for tasks to exit
|
|
p.join()
|
|
|
|
# Output results
|
|
for k, v in sorted(d.items()):
|
|
print k, v
|
|
|
|
This will produce the output::
|
|
|
|
1 1
|
|
11 39916800
|
|
21 51090942171709440000
|
|
31 8222838654177922817725562880000000
|
|
41 33452526613163807108170062053440751665152000000000
|
|
51 1551118753287382280224243016469303211063259720016986112000000000000
|
|
|
|
.. seealso::
|
|
|
|
The documentation for the :mod:`multiprocessing` module.
|
|
|
|
:pep:`371` - Addition of the multiprocessing package
|
|
PEP written by Jesse Noller and Richard Oudkerk;
|
|
implemented by Richard Oudkerk and Jesse Noller.
|
|
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-3101:
|
|
|
|
PEP 3101: Advanced String Formatting
|
|
=====================================================
|
|
|
|
In Python 3.0, the `%` operator is supplemented by a more powerful string
|
|
formatting method, :meth:`format`. Support for the :meth:`str.format` method
|
|
has been backported to Python 2.6.
|
|
|
|
In 2.6, both 8-bit and Unicode strings have a `.format()` method that
|
|
treats the string as a template and takes the arguments to be formatted.
|
|
The formatting template uses curly brackets (`{`, `}`) as special characters::
|
|
|
|
# Substitute positional argument 0 into the string.
|
|
"User ID: {0}".format("root") -> "User ID: root"
|
|
|
|
# Use the named keyword arguments
|
|
uid = 'root'
|
|
|
|
'User ID: {uid} Last seen: {last_login}'.format(uid='root',
|
|
last_login = '5 Mar 2008 07:20') ->
|
|
'User ID: root Last seen: 5 Mar 2008 07:20'
|
|
|
|
Curly brackets can be escaped by doubling them::
|
|
|
|
format("Empty dict: {{}}") -> "Empty dict: {}"
|
|
|
|
Field names can be integers indicating positional arguments, such as
|
|
``{0}``, ``{1}``, etc. or names of keyword arguments. You can also
|
|
supply compound field names that read attributes or access dictionary keys::
|
|
|
|
import sys
|
|
'Platform: {0.platform}\nPython version: {0.version}'.format(sys) ->
|
|
'Platform: darwin\n
|
|
Python version: 2.6a1+ (trunk:61261M, Mar 5 2008, 20:29:41) \n
|
|
[GCC 4.0.1 (Apple Computer, Inc. build 5367)]'
|
|
|
|
import mimetypes
|
|
'Content-type: {0[.mp4]}'.format(mimetypes.types_map) ->
|
|
'Content-type: video/mp4'
|
|
|
|
Note that when using dictionary-style notation such as ``[.mp4]``, you
|
|
don't need to put any quotation marks around the string; it will look
|
|
up the value using ``.mp4`` as the key. Strings beginning with a
|
|
number will be converted to an integer. You can't write more
|
|
complicated expressions inside a format string.
|
|
|
|
So far we've shown how to specify which field to substitute into the
|
|
resulting string. The precise formatting used is also controllable by
|
|
adding a colon followed by a format specifier. For example::
|
|
|
|
# Field 0: left justify, pad to 15 characters
|
|
# Field 1: right justify, pad to 6 characters
|
|
fmt = '{0:15} ${1:>6}'
|
|
fmt.format('Registration', 35) ->
|
|
'Registration $ 35'
|
|
fmt.format('Tutorial', 50) ->
|
|
'Tutorial $ 50'
|
|
fmt.format('Banquet', 125) ->
|
|
'Banquet $ 125'
|
|
|
|
Format specifiers can reference other fields through nesting::
|
|
|
|
fmt = '{0:{1}}'
|
|
fmt.format('Invoice #1234', 15) ->
|
|
'Invoice #1234 '
|
|
width = 35
|
|
fmt.format('Invoice #1234', width) ->
|
|
'Invoice #1234 '
|
|
|
|
The alignment of a field within the desired width can be specified:
|
|
|
|
================ ============================================
|
|
Character Effect
|
|
================ ============================================
|
|
< (default) Left-align
|
|
> Right-align
|
|
^ Center
|
|
= (For numeric types only) Pad after the sign.
|
|
================ ============================================
|
|
|
|
Format specifiers can also include a presentation type, which
|
|
controls how the value is formatted. For example, floating-point numbers
|
|
can be formatted as a general number or in exponential notation:
|
|
|
|
>>> '{0:g}'.format(3.75)
|
|
'3.75'
|
|
>>> '{0:e}'.format(3.75)
|
|
'3.750000e+00'
|
|
|
|
A variety of presentation types are available. Consult the 2.6
|
|
documentation for a :ref:`complete list <formatstrings>`; here's a sample::
|
|
|
|
'b' - Binary. Outputs the number in base 2.
|
|
'c' - Character. Converts the integer to the corresponding
|
|
Unicode character before printing.
|
|
'd' - Decimal Integer. Outputs the number in base 10.
|
|
'o' - Octal format. Outputs the number in base 8.
|
|
'x' - Hex format. Outputs the number in base 16, using lower-
|
|
case letters for the digits above 9.
|
|
'e' - Exponent notation. Prints the number in scientific
|
|
notation using the letter 'e' to indicate the exponent.
|
|
'g' - General format. This prints the number as a fixed-point
|
|
number, unless the number is too large, in which case
|
|
it switches to 'e' exponent notation.
|
|
'n' - Number. This is the same as 'g' (for floats) or 'd' (for
|
|
integers), except that it uses the current locale setting to
|
|
insert the appropriate number separator characters.
|
|
'%' - Percentage. Multiplies the number by 100 and displays
|
|
in fixed ('f') format, followed by a percent sign.
|
|
|
|
Classes and types can define a :meth:`__format__` method to control how they're
|
|
formatted. It receives a single argument, the format specifier::
|
|
|
|
def __format__(self, format_spec):
|
|
if isinstance(format_spec, unicode):
|
|
return unicode(str(self))
|
|
else:
|
|
return str(self)
|
|
|
|
There's also a format() built-in that will format a single value. It calls
|
|
the type's :meth:`__format__` method with the provided specifier::
|
|
|
|
>>> format(75.6564, '.2f')
|
|
'75.66'
|
|
|
|
|
|
.. seealso::
|
|
|
|
:ref:`formatstrings`
|
|
The reference format fields.
|
|
|
|
:pep:`3101` - Advanced String Formatting
|
|
PEP written by Talin. Implemented by Eric Smith.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-3105:
|
|
|
|
PEP 3105: ``print`` As a Function
|
|
=====================================================
|
|
|
|
The ``print`` statement becomes the :func:`print` function in Python 3.0.
|
|
Making :func:`print` a function makes it easier to change
|
|
by doing 'def print(...)' or importing a new function from somewhere else.
|
|
|
|
Python 2.6 has a ``__future__`` import that removes ``print`` as language
|
|
syntax, letting you use the functional form instead. For example::
|
|
|
|
from __future__ import print_function
|
|
print('# of entries', len(dictionary), file=sys.stderr)
|
|
|
|
The signature of the new function is::
|
|
|
|
def print(*args, sep=' ', end='\n', file=None)
|
|
|
|
The parameters are:
|
|
|
|
* **args**: positional arguments whose values will be printed out.
|
|
* **sep**: the separator, which will be printed between arguments.
|
|
* **end**: the ending text, which will be printed after all of the
|
|
arguments have been output.
|
|
* **file**: the file object to which the output will be sent.
|
|
|
|
.. seealso::
|
|
|
|
:pep:`3105` - Make print a function
|
|
PEP written by Georg Brandl.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-3110:
|
|
|
|
PEP 3110: Exception-Handling Changes
|
|
=====================================================
|
|
|
|
One error that Python programmers occasionally make
|
|
is the following::
|
|
|
|
try:
|
|
...
|
|
except TypeError, ValueError:
|
|
...
|
|
|
|
The author is probably trying to catch both
|
|
:exc:`TypeError` and :exc:`ValueError` exceptions, but this code
|
|
actually does something different: it will catch
|
|
:exc:`TypeError` and bind the resulting exception object
|
|
to the local name ``"ValueError"``. The correct code
|
|
would have specified a tuple::
|
|
|
|
try:
|
|
...
|
|
except (TypeError, ValueError):
|
|
...
|
|
|
|
This error is possible because the use of the comma here is ambiguous:
|
|
does it indicate two different nodes in the parse tree, or a single
|
|
node that's a tuple.
|
|
|
|
Python 3.0 changes the syntax to make this unambiguous by replacing
|
|
the comma with the word "as". To catch an exception and store the
|
|
exception object in the variable ``exc``, you must write::
|
|
|
|
try:
|
|
...
|
|
except TypeError as exc:
|
|
...
|
|
|
|
Python 3.0 will only support the use of "as", and therefore interprets
|
|
the first example as catching two different exceptions. Python 2.6
|
|
supports both the comma and "as", so existing code will continue to
|
|
work.
|
|
|
|
.. seealso::
|
|
|
|
:pep:`3110` - Catching Exceptions in Python 3000
|
|
PEP written and implemented by Collin Winter.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-3112:
|
|
|
|
PEP 3112: Byte Literals
|
|
=====================================================
|
|
|
|
Python 3.0 adopts Unicode as the language's fundamental string type and
|
|
denotes 8-bit literals differently, either as ``b'string'``
|
|
or using a :class:`bytes` constructor. For future compatibility,
|
|
Python 2.6 adds :class:`bytes` as a synonym for the :class:`str` type,
|
|
and it also supports the ``b''`` notation.
|
|
|
|
There's also a ``__future__`` import that causes all string literals
|
|
to become Unicode strings. This means that ``\u`` escape sequences
|
|
can be used to include Unicode characters::
|
|
|
|
|
|
from __future__ import unicode_literals
|
|
|
|
s = ('\u751f\u3080\u304e\u3000\u751f\u3054'
|
|
'\u3081\u3000\u751f\u305f\u307e\u3054')
|
|
|
|
print len(s) # 12 Unicode characters
|
|
|
|
At the C level, Python 3.0 will rename the existing 8-bit
|
|
string type, called :ctype:`PyStringObject` in Python 2.x,
|
|
to :ctype:`PyBytesObject`. Python 2.6 uses ``#define``
|
|
to support using the names :cfunc:`PyBytesObject`,
|
|
:cfunc:`PyBytes_Check`, :cfunc:`PyBytes_FromStringAndSize`,
|
|
and all the other functions and macros used with strings.
|
|
|
|
Instances of the :class:`bytes` type are immutable just
|
|
as strings are. A new :class:`bytearray` type stores a mutable
|
|
sequence of bytes::
|
|
|
|
>>> bytearray([65, 66, 67])
|
|
bytearray(b'ABC')
|
|
>>> b = bytearray(u'\u21ef\u3244', 'utf-8')
|
|
>>> b
|
|
bytearray(b'\xe2\x87\xaf \xe3\x89\x84')
|
|
>>> b[0] = '\xe3'
|
|
>>> b
|
|
bytearray(b'\xe3\x87\xaf \xe3\x89\x84')
|
|
>>> unicode(str(b), 'utf-8')
|
|
u'\u31ef \u3244'
|
|
|
|
Byte arrays support most of the methods of string types, such as
|
|
:meth:`startswith`/:meth:`endswith`, :meth:`find`/:meth:`rfind`,
|
|
and some of the methods of lists, such as :meth:`append`,
|
|
:meth:`pop`, and :meth:`reverse`.
|
|
|
|
>>> b = bytearray('ABC')
|
|
>>> b.append('d')
|
|
>>> b.append(ord('e'))
|
|
>>> b
|
|
bytearray(b'ABCde')
|
|
|
|
.. seealso::
|
|
|
|
:pep:`3112` - Bytes literals in Python 3000
|
|
PEP written by Jason Orendorff; backported to 2.6 by Christian Heimes.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-3116:
|
|
|
|
PEP 3116: New I/O Library
|
|
=====================================================
|
|
|
|
Python's built-in file objects support a number of methods, but
|
|
file-like objects don't necessarily support all of them. Objects that
|
|
imitate files usually support :meth:`read` and :meth:`write`, but they
|
|
may not support :meth:`readline`. Python 3.0 introduces a layered I/O
|
|
library in the :mod:`io` module that separates buffering and
|
|
text-handling features from the fundamental read and write operations.
|
|
|
|
There are three levels of abstract base classes provided by
|
|
the :mod:`io` module:
|
|
|
|
* :class:`RawIOBase`: defines raw I/O operations: :meth:`read`,
|
|
:meth:`readinto`,
|
|
:meth:`write`, :meth:`seek`, :meth:`tell`, :meth:`truncate`,
|
|
and :meth:`close`.
|
|
Most of the methods of this class will often map to a single system call.
|
|
There are also :meth:`readable`, :meth:`writable`, and :meth:`seekable`
|
|
methods for determining what operations a given object will allow.
|
|
|
|
Python 3.0 has concrete implementations of this class for files and
|
|
sockets, but Python 2.6 hasn't restructured its file and socket objects
|
|
in this way.
|
|
|
|
.. XXX should 2.6 register them in io.py?
|
|
|
|
* :class:`BufferedIOBase`: is an abstract base class that
|
|
buffers data in memory to reduce the number of
|
|
system calls used, making I/O processing more efficient.
|
|
It supports all of the methods of :class:`RawIOBase`,
|
|
and adds a :attr:`raw` attribute holding the underlying raw object.
|
|
|
|
There are four concrete classes implementing this ABC:
|
|
:class:`BufferedWriter` and
|
|
:class:`BufferedReader` for objects that only support
|
|
writing or reading and don't support random access,
|
|
:class:`BufferedRandom` for objects that support the :meth:`seek` method
|
|
for random access,
|
|
and :class:`BufferedRWPair` for objects such as TTYs that have
|
|
both read and write operations that act upon unconnected streams of data.
|
|
|
|
* :class:`TextIOBase`: Provides functions for reading and writing
|
|
strings (remember, strings will be Unicode in Python 3.0),
|
|
and supporting universal newlines. :class:`TextIOBase` defines
|
|
the :meth:`readline` method and supports iteration upon
|
|
objects.
|
|
|
|
There are two concrete implementations. :class:`TextIOWrapper`
|
|
wraps a buffered I/O object, supporting all of the methods for
|
|
text I/O and adding a :attr:`buffer` attribute for access
|
|
to the underlying object. :class:`StringIO` simply buffers
|
|
everything in memory without ever writing anything to disk.
|
|
|
|
(In current 2.6 alpha releases, :class:`io.StringIO` is implemented in
|
|
pure Python, so it's pretty slow. You should therefore stick with the
|
|
existing :mod:`StringIO` module or :mod:`cStringIO` for now. At some
|
|
point Python 3.0's :mod:`io` module will be rewritten into C for speed,
|
|
and perhaps the C implementation will be backported to the 2.x releases.)
|
|
|
|
.. XXX check before final release: is io.py still written in Python?
|
|
|
|
In Python 2.6, the underlying implementations haven't been
|
|
restructured to build on top of the :mod:`io` module's classes. The
|
|
module is being provided to make it easier to write code that's
|
|
forward-compatible with 3.0, and to save developers the effort of writing
|
|
their own implementations of buffering and text I/O.
|
|
|
|
.. seealso::
|
|
|
|
:pep:`3116` - New I/O
|
|
PEP written by Daniel Stutzbach, Mike Verdone, and Guido van Rossum.
|
|
Code by Guido van Rossum, Georg Brandl, Walter Doerwald,
|
|
Jeremy Hylton, Martin von Loewis, Tony Lownds, and others.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-3118:
|
|
|
|
PEP 3118: Revised Buffer Protocol
|
|
=====================================================
|
|
|
|
The buffer protocol is a C-level API that lets Python types
|
|
exchange pointers into their internal representations. A
|
|
memory-mapped file can be viewed as a buffer of characters, for
|
|
example, and this lets another module such as :mod:`re`
|
|
treat memory-mapped files as a string of characters to be searched.
|
|
|
|
The primary users of the buffer protocol are numeric-processing
|
|
packages such as NumPy, which can expose the internal representation
|
|
of arrays so that callers can write data directly into an array instead
|
|
of going through a slower API. This PEP updates the buffer protocol in light of experience
|
|
from NumPy development, adding a number of new features
|
|
such as indicating the shape of an array,
|
|
locking memory .
|
|
|
|
The most important new C API function is
|
|
``PyObject_GetBuffer(PyObject *obj, Py_buffer *view, int flags)``, which
|
|
takes an object and a set of flags, and fills in the
|
|
``Py_buffer`` structure with information
|
|
about the object's memory representation. Objects
|
|
can use this operation to lock memory in place
|
|
while an external caller could be modifying the contents,
|
|
so there's a corresponding
|
|
``PyBuffer_Release(Py_buffer *view)`` to
|
|
indicate that the external caller is done.
|
|
|
|
The **flags** argument to :cfunc:`PyObject_GetBuffer` specifies
|
|
constraints upon the memory returned. Some examples are:
|
|
|
|
* :const:`PyBUF_WRITABLE` indicates that the memory must be writable.
|
|
|
|
* :const:`PyBUF_LOCK` requests a read-only or exclusive lock on the memory.
|
|
|
|
* :const:`PyBUF_C_CONTIGUOUS` and :const:`PyBUF_F_CONTIGUOUS`
|
|
requests a C-contiguous (last dimension varies the fastest) or
|
|
Fortran-contiguous (first dimension varies the fastest) layout.
|
|
|
|
.. XXX this feature is not in 2.6 docs yet
|
|
|
|
.. seealso::
|
|
|
|
:pep:`3118` - Revising the buffer protocol
|
|
PEP written by Travis Oliphant and Carl Banks; implemented by
|
|
Travis Oliphant.
|
|
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-3119:
|
|
|
|
PEP 3119: Abstract Base Classes
|
|
=====================================================
|
|
|
|
Some object-oriented languages such as Java support interfaces: declarations
|
|
that a class has a given set of methods or supports a given access protocol.
|
|
Abstract Base Classes (or ABCs) are an equivalent feature for Python. The ABC
|
|
support consists of an :mod:`abc` module containing a metaclass called
|
|
:class:`ABCMeta`, special handling
|
|
of this metaclass by the :func:`isinstance` and :func:`issubclass` built-ins,
|
|
and a collection of basic ABCs that the Python developers think will be widely
|
|
useful.
|
|
|
|
Let's say you have a particular class and wish to know whether it supports
|
|
dictionary-style access. The phrase "dictionary-style" is vague, however.
|
|
It probably means that accessing items with ``obj[1]`` works.
|
|
Does it imply that setting items with ``obj[2] = value`` works?
|
|
Or that the object will have :meth:`keys`, :meth:`values`, and :meth:`items`
|
|
methods? What about the iterative variants such as :meth:`iterkeys`? :meth:`copy`
|
|
and :meth:`update`? Iterating over the object with :func:`iter`?
|
|
|
|
Python 2.6 includes a number of different ABCs in the :mod:`collections`
|
|
module. :class:`Iterable` indicates that a class defines :meth:`__iter__`,
|
|
and :class:`Container` means the class supports ``x in y`` expressions
|
|
by defining a :meth:`__contains__` method. The basic dictionary interface of
|
|
getting items, setting items, and
|
|
:meth:`keys`, :meth:`values`, and :meth:`items`, is defined by the
|
|
:class:`MutableMapping` ABC.
|
|
|
|
You can derive your own classes from a particular ABC
|
|
to indicate they support that ABC's interface::
|
|
|
|
import collections
|
|
|
|
class Storage(collections.MutableMapping):
|
|
...
|
|
|
|
|
|
Alternatively, you could write the class without deriving from
|
|
the desired ABC and instead register the class by
|
|
calling the ABC's :meth:`register` method::
|
|
|
|
import collections
|
|
|
|
class Storage:
|
|
...
|
|
|
|
collections.MutableMapping.register(Storage)
|
|
|
|
For classes that you write, deriving from the ABC is probably clearer.
|
|
The :meth:`register` method is useful when you've written a new
|
|
ABC that can describe an existing type or class, or if you want
|
|
to declare that some third-party class implements an ABC.
|
|
For example, if you defined a :class:`PrintableType` ABC,
|
|
it's legal to do::
|
|
|
|
# Register Python's types
|
|
PrintableType.register(int)
|
|
PrintableType.register(float)
|
|
PrintableType.register(str)
|
|
|
|
Classes should obey the semantics specified by an ABC, but
|
|
Python can't check this; it's up to the class author to
|
|
understand the ABC's requirements and to implement the code accordingly.
|
|
|
|
To check whether an object supports a particular interface, you can
|
|
now write::
|
|
|
|
def func(d):
|
|
if not isinstance(d, collections.MutableMapping):
|
|
raise ValueError("Mapping object expected, not %r" % d)
|
|
|
|
(Don't feel that you must now begin writing lots of checks as in the
|
|
above example. Python has a strong tradition of duck-typing, where
|
|
explicit type-checking isn't done and code simply calls methods on
|
|
an object, trusting that those methods will be there and raising an
|
|
exception if they aren't. Be judicious in checking for ABCs
|
|
and only do it where it helps.)
|
|
|
|
You can write your own ABCs by using ``abc.ABCMeta`` as the
|
|
metaclass in a class definition::
|
|
|
|
from abc import ABCMeta
|
|
|
|
class Drawable():
|
|
__metaclass__ = ABCMeta
|
|
|
|
def draw(self, x, y, scale=1.0):
|
|
pass
|
|
|
|
def draw_doubled(self, x, y):
|
|
self.draw(x, y, scale=2.0)
|
|
|
|
|
|
class Square(Drawable):
|
|
def draw(self, x, y, scale):
|
|
...
|
|
|
|
|
|
In the :class:`Drawable` ABC above, the :meth:`draw_doubled` method
|
|
renders the object at twice its size and can be implemented in terms
|
|
of other methods described in :class:`Drawable`. Classes implementing
|
|
this ABC therefore don't need to provide their own implementation
|
|
of :meth:`draw_doubled`, though they can do so. An implementation
|
|
of :meth:`draw` is necessary, though; the ABC can't provide
|
|
a useful generic implementation. You
|
|
can apply the ``@abstractmethod`` decorator to methods such as
|
|
:meth:`draw` that must be implemented; Python will
|
|
then raise an exception for classes that
|
|
don't define the method::
|
|
|
|
class Drawable():
|
|
__metaclass__ = ABCMeta
|
|
|
|
@abstractmethod
|
|
def draw(self, x, y, scale):
|
|
pass
|
|
|
|
Note that the exception is only raised when you actually
|
|
try to create an instance of a subclass without the method::
|
|
|
|
>>> s=Square()
|
|
Traceback (most recent call last):
|
|
File "<stdin>", line 1, in <module>
|
|
TypeError: Can't instantiate abstract class Square with abstract methods draw
|
|
>>>
|
|
|
|
Abstract data attributes can be declared using the ``@abstractproperty`` decorator::
|
|
|
|
@abstractproperty
|
|
def readonly(self):
|
|
return self._x
|
|
|
|
Subclasses must then define a :meth:`readonly` property
|
|
|
|
.. seealso::
|
|
|
|
:pep:`3119` - Introducing Abstract Base Classes
|
|
PEP written by Guido van Rossum and Talin.
|
|
Implemented by Guido van Rossum.
|
|
Backported to 2.6 by Benjamin Aranguren, with Alex Martelli.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-3127:
|
|
|
|
PEP 3127: Integer Literal Support and Syntax
|
|
=====================================================
|
|
|
|
Python 3.0 changes the syntax for octal (base-8) integer literals,
|
|
which are now prefixed by "0o" or "0O" instead of a leading zero, and
|
|
adds support for binary (base-2) integer literals, signalled by a "0b"
|
|
or "0B" prefix.
|
|
|
|
Python 2.6 doesn't drop support for a leading 0 signalling
|
|
an octal number, but it does add support for "0o" and "0b"::
|
|
|
|
>>> 0o21, 2*8 + 1
|
|
(17, 17)
|
|
>>> 0b101111
|
|
47
|
|
|
|
The :func:`oct` built-in still returns numbers
|
|
prefixed with a leading zero, and a new :func:`bin`
|
|
built-in returns the binary representation for a number::
|
|
|
|
>>> oct(42)
|
|
'052'
|
|
>>> bin(173)
|
|
'0b10101101'
|
|
|
|
The :func:`int` and :func:`long` built-ins will now accept the "0o"
|
|
and "0b" prefixes when base-8 or base-2 are requested, or when the
|
|
**base** argument is zero (meaning the base used is determined from
|
|
the string):
|
|
|
|
>>> int ('0o52', 0)
|
|
42
|
|
>>> int('1101', 2)
|
|
13
|
|
>>> int('0b1101', 2)
|
|
13
|
|
>>> int('0b1101', 0)
|
|
13
|
|
|
|
|
|
.. seealso::
|
|
|
|
:pep:`3127` - Integer Literal Support and Syntax
|
|
PEP written by Patrick Maupin; backported to 2.6 by
|
|
Eric Smith.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-3129:
|
|
|
|
PEP 3129: Class Decorators
|
|
=====================================================
|
|
|
|
Decorators have been extended from functions to classes. It's now legal to
|
|
write::
|
|
|
|
@foo
|
|
@bar
|
|
class A:
|
|
pass
|
|
|
|
This is equivalent to::
|
|
|
|
class A:
|
|
pass
|
|
|
|
A = foo(bar(A))
|
|
|
|
.. seealso::
|
|
|
|
:pep:`3129` - Class Decorators
|
|
PEP written by Collin Winter.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _pep-3141:
|
|
|
|
PEP 3141: A Type Hierarchy for Numbers
|
|
=====================================================
|
|
|
|
In Python 3.0, several abstract base classes for numeric types,
|
|
inspired by Scheme's numeric tower, are being added.
|
|
This change was backported to 2.6 as the :mod:`numbers` module.
|
|
|
|
The most general ABC is :class:`Number`. It defines no operations at
|
|
all, and only exists to allow checking if an object is a number by
|
|
doing ``isinstance(obj, Number)``.
|
|
|
|
:class:`Complex` is a subclass of :class:`Number`. Complex numbers
|
|
can undergo the basic operations of addition, subtraction,
|
|
multiplication, division, and exponentiation, and you can retrieve the
|
|
real and imaginary parts and obtain a number's conjugate. Python's built-in
|
|
complex type is an implementation of :class:`Complex`.
|
|
|
|
:class:`Real` further derives from :class:`Complex`, and adds
|
|
operations that only work on real numbers: :func:`floor`, :func:`trunc`,
|
|
rounding, taking the remainder mod N, floor division,
|
|
and comparisons.
|
|
|
|
:class:`Rational` numbers derive from :class:`Real`, have
|
|
:attr:`numerator` and :attr:`denominator` properties, and can be
|
|
converted to floats. Python 2.6 adds a simple rational-number class,
|
|
:class:`Fraction`, in the :mod:`fractions` module. (It's called
|
|
:class:`Fraction` instead of :class:`Rational` to avoid
|
|
a name clash with :class:`numbers.Rational`.)
|
|
|
|
:class:`Integral` numbers derive from :class:`Rational`, and
|
|
can be shifted left and right with ``<<`` and ``>>``,
|
|
combined using bitwise operations such as ``&`` and ``|``,
|
|
and can be used as array indexes and slice boundaries.
|
|
|
|
In Python 3.0, the PEP slightly redefines the existing built-ins
|
|
:func:`round`, :func:`math.floor`, :func:`math.ceil`, and adds a new
|
|
one, :func:`math.trunc`, that's been backported to Python 2.6.
|
|
:func:`math.trunc` rounds toward zero, returning the closest
|
|
:class:`Integral` that's between the function's argument and zero.
|
|
|
|
.. seealso::
|
|
|
|
:pep:`3141` - A Type Hierarchy for Numbers
|
|
PEP written by Jeffrey Yasskin.
|
|
|
|
`Scheme's numerical tower <http://www.gnu.org/software/guile/manual/html_node/Numerical-Tower.html#Numerical-Tower>`__, from the Guile manual.
|
|
|
|
`Scheme's number datatypes <http://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.2>`__ from the R5RS Scheme specification.
|
|
|
|
|
|
The :mod:`fractions` Module
|
|
--------------------------------------------------
|
|
|
|
To fill out the hierarchy of numeric types, a rational-number class is
|
|
provided by the :mod:`fractions` module. Rational numbers store their
|
|
values as a numerator and denominator forming a fraction, and can
|
|
exactly represent numbers such as ``2/3`` that floating-point numbers
|
|
can only approximate.
|
|
|
|
The :class:`Fraction` constructor takes two :class:`Integral` values
|
|
that will be the numerator and denominator of the resulting fraction. ::
|
|
|
|
>>> from fractions import Fraction
|
|
>>> a = Fraction(2, 3)
|
|
>>> b = Fraction(2, 5)
|
|
>>> float(a), float(b)
|
|
(0.66666666666666663, 0.40000000000000002)
|
|
>>> a+b
|
|
Fraction(16, 15)
|
|
>>> a/b
|
|
Fraction(5, 3)
|
|
|
|
To help in converting floating-point numbers to rationals,
|
|
the float type now has a :meth:`as_integer_ratio()` method that returns
|
|
the numerator and denominator for a fraction that evaluates to the same
|
|
floating-point value::
|
|
|
|
>>> (2.5) .as_integer_ratio()
|
|
(5, 2)
|
|
>>> (3.1415) .as_integer_ratio()
|
|
(7074029114692207L, 2251799813685248L)
|
|
>>> (1./3) .as_integer_ratio()
|
|
(6004799503160661L, 18014398509481984L)
|
|
|
|
Note that values that can only be approximated by floating-point
|
|
numbers, such as 1./3, are not simplified to the number being
|
|
approximated; the fraction attempts to match the floating-point value
|
|
**exactly**.
|
|
|
|
The :mod:`fractions` module is based upon an implementation by Sjoerd
|
|
Mullender that was in Python's :file:`Demo/classes/` directory for a
|
|
long time. This implementation was significantly updated by Jeffrey
|
|
Yasskin.
|
|
|
|
|
|
Other Language Changes
|
|
======================
|
|
|
|
Here are all of the changes that Python 2.6 makes to the core Python language.
|
|
|
|
* The :func:`hasattr` function was catching and ignoring all errors,
|
|
under the assumption that they meant a :meth:`__getattr__` method
|
|
was failing somewhere and the return value of :func:`hasattr` would
|
|
therefore be ``False``. This logic shouldn't be applied to
|
|
:exc:`KeyboardInterrupt` and :exc:`SystemExit`, however; Python 2.6
|
|
will no longer discard such exceptions when :func:`hasattr`
|
|
encounters them. (Fixed by Benjamin Peterson; :issue:`2196`.)
|
|
|
|
* When calling a function using the ``**`` syntax to provide keyword
|
|
arguments, you are no longer required to use a Python dictionary;
|
|
any mapping will now work::
|
|
|
|
>>> def f(**kw):
|
|
... print sorted(kw)
|
|
...
|
|
>>> ud=UserDict.UserDict()
|
|
>>> ud['a'] = 1
|
|
>>> ud['b'] = 'string'
|
|
>>> f(**ud)
|
|
['a', 'b']
|
|
|
|
(Contributed by Alexander Belopolsky; :issue:`1686487`.)
|
|
|
|
* A new built-in, ``next(*iterator*, [*default*])`` returns the next item
|
|
from the specified iterator. If the *default* argument is supplied,
|
|
it will be returned if *iterator* has been exhausted; otherwise,
|
|
the :exc:`StopIteration` exception will be raised. (:issue:`2719`)
|
|
|
|
* Tuples now have :meth:`index` and :meth:`count` methods matching the
|
|
list type's :meth:`index` and :meth:`count` methods::
|
|
|
|
>>> t = (0,1,2,3,4)
|
|
>>> t.index(3)
|
|
3
|
|
|
|
(Contributed by Raymond Hettinger)
|
|
|
|
* The built-in types now have improved support for extended slicing syntax,
|
|
where various combinations of ``(start, stop, step)`` are supplied.
|
|
Previously, the support was partial and certain corner cases wouldn't work.
|
|
(Implemented by Thomas Wouters.)
|
|
|
|
.. Revision 57619
|
|
|
|
* Properties now have three attributes, :attr:`getter`,
|
|
:attr:`setter` and :attr:`deleter`, that are useful shortcuts for
|
|
adding or modifying a getter, setter or deleter function to an
|
|
existing property. You would use them like this::
|
|
|
|
class C(object):
|
|
@property
|
|
def x(self):
|
|
return self._x
|
|
|
|
@x.setter
|
|
def x(self, value):
|
|
self._x = value
|
|
|
|
@x.deleter
|
|
def x(self):
|
|
del self._x
|
|
|
|
class D(C):
|
|
@C.x.getter
|
|
def x(self):
|
|
return self._x * 2
|
|
|
|
@x.setter
|
|
def x(self, value):
|
|
self._x = value / 2
|
|
|
|
* Several methods of the built-in set types now accept multiple iterables:
|
|
:meth:`intersection`,
|
|
:meth:`intersection_update`,
|
|
:meth:`union`, :meth:`update`,
|
|
:meth:`difference` and :meth:`difference_update`.
|
|
|
|
::
|
|
|
|
>>> s=set('1234567890')
|
|
>>> s.intersection('abc123', 'cdf246') # Intersection between all inputs
|
|
set(['2'])
|
|
>>> s.difference('246', '789')
|
|
set(['1', '0', '3', '5'])
|
|
|
|
(Contributed by Raymond Hettinger.)
|
|
|
|
* A numerical nicety: when creating a complex number from two floats
|
|
on systems that support signed zeros (-0 and +0), the
|
|
:func:`complex` constructor will now preserve the sign
|
|
of the zero. (Fixed by Mark T. Dickinson; :issue:`1507`)
|
|
|
|
* More floating-point features were also added. The :func:`float` function
|
|
will now turn the string ``nan`` into an
|
|
IEEE 754 Not A Number value, and ``+inf`` and ``-inf`` into
|
|
positive or negative infinity. This works on any platform with
|
|
IEEE 754 semantics. (Contributed by Christian Heimes; :issue:`1635`.)
|
|
|
|
Other functions in the :mod:`math` module, :func:`isinf` and
|
|
:func:`isnan`, return true if their floating-point argument is
|
|
infinite or Not A Number. (:issue:`1640`)
|
|
|
|
Conversion functions were added to convert floating-point numbers
|
|
into hexadecimal strings. (:issue:`3008`) These functions lets you
|
|
convert floats to and from a string representation without
|
|
introducing rounding errors from the conversion between decimal and
|
|
binary. Floats have a :meth:`hex` method that returns a string
|
|
representation, and the ``float.fromhex()`` method converts a string
|
|
back into a number::
|
|
|
|
>>> a = 3.75
|
|
>>> a.hex()
|
|
'0x1.e000000000000p+1'
|
|
>>> float.fromhex('0x1.e000000000000p+1')
|
|
3.75
|
|
>>> b=1./3
|
|
>>> b.hex()
|
|
'0x1.5555555555555p-2'
|
|
|
|
* The :mod:`math` module has a number of new functions, and the existing
|
|
functions have been improved to give more consistent behaviour
|
|
across platforms, especially with respect to handling of
|
|
floating-point exceptions and IEEE 754 special values.
|
|
The new functions are:
|
|
|
|
* :func:`~math.isinf` and :func:`~math.isnan` determine whether a given float
|
|
is a (positive or negative) infinity or a NaN (Not a Number), respectively.
|
|
|
|
* :func:`~math.copysign` copies the sign bit of an IEEE 754 number,
|
|
returning the absolute value of *x* combined with the sign bit of
|
|
*y*. For example, ``math.copysign(1, -0.0)`` returns -1.0.
|
|
(Contributed by Christian Heimes.)
|
|
|
|
* :func:`~math.factorial` computes the factorial of a number.
|
|
(Contributed by Raymond Hettinger; :issue:`2138`.)
|
|
|
|
* :func:`~math.fsum` adds up the stream of numbers from an iterable,
|
|
and is careful to avoid loss of precision by calculating partial sums.
|
|
(Contributed by Jean Brouwers, Raymond Hettinger, and Mark Dickinson;
|
|
:issue:`2819`.)
|
|
|
|
* The inverse hyperbolic functions :func:`~math.acosh`, :func:`~math.asinh`
|
|
and :func:`~math.atanh`.
|
|
|
|
* The function :func:`~math.log1p`, returning the natural logarithm of *1+x*
|
|
(base *e*).
|
|
|
|
There's also a new :func:`trunc` built-in function as a result of the
|
|
backport of `PEP 3141's type hierarchy for numbers <#pep-3141>`__.
|
|
|
|
The existing math functions have been modified to follow the
|
|
recommendations of the C99 standard with respect to special values
|
|
whenever possible. For example, ``sqrt(-1.)`` should now give a
|
|
:exc:`ValueError` across (nearly) all platforms, while
|
|
``sqrt(float('NaN'))`` should return a NaN on all IEEE 754
|
|
platforms. Where Annex 'F' of the C99 standard recommends signaling
|
|
'divide-by-zero' or 'invalid', Python will raise :exc:`ValueError`.
|
|
Where Annex 'F' of the C99 standard recommends signaling 'overflow',
|
|
Python will raise :exc:`OverflowError`. (See :issue:`711019`,
|
|
:issue:`1640`.)
|
|
|
|
(Contributed by Christian Heimes and Mark Dickinson.)
|
|
|
|
* Changes to the :class:`Exception` interface
|
|
as dictated by :pep:`352` continue to be made. For 2.6,
|
|
the :attr:`message` attribute is being deprecated in favor of the
|
|
:attr:`args` attribute.
|
|
|
|
* The :exc:`GeneratorExit` exception now subclasses
|
|
:exc:`BaseException` instead of :exc:`Exception`. This means
|
|
that an exception handler that does ``except Exception:``
|
|
will not inadvertently catch :exc:`GeneratorExit`.
|
|
(Contributed by Chad Austin; :issue:`1537`.)
|
|
|
|
* Generator objects now have a :attr:`gi_code` attribute that refers to
|
|
the original code object backing the generator.
|
|
(Contributed by Collin Winter; :issue:`1473257`.)
|
|
|
|
* The :func:`compile` built-in function now accepts keyword arguments
|
|
as well as positional parameters. (Contributed by Thomas Wouters;
|
|
:issue:`1444529`.)
|
|
|
|
* The :func:`complex` constructor now accepts strings containing
|
|
parenthesized complex numbers, letting ``complex(repr(cmplx))``
|
|
will now round-trip values. For example, ``complex('(3+4j)')``
|
|
now returns the value (3+4j). (:issue:`1491866`)
|
|
|
|
* The string :meth:`translate` method now accepts ``None`` as the
|
|
translation table parameter, which is treated as the identity
|
|
transformation. This makes it easier to carry out operations
|
|
that only delete characters. (Contributed by Bengt Richter and
|
|
implemented by Raymond Hettinger; :issue:`1193128`.)
|
|
|
|
* The built-in :func:`dir` function now checks for a :meth:`__dir__`
|
|
method on the objects it receives. This method must return a list
|
|
of strings containing the names of valid attributes for the object,
|
|
and lets the object control the value that :func:`dir` produces.
|
|
Objects that have :meth:`__getattr__` or :meth:`__getattribute__`
|
|
methods can use this to advertise pseudo-attributes they will honor.
|
|
(:issue:`1591665`)
|
|
|
|
* Instance method objects have new attributes for the object and function
|
|
comprising the method; the new synonym for :attr:`im_self` is
|
|
:attr:`__self__`, and :attr:`im_func` is also available as :attr:`__func__`.
|
|
The old names are still supported in Python 2.6; they're gone in 3.0.
|
|
|
|
* An obscure change: when you use the the :func:`locals` function inside a
|
|
:keyword:`class` statement, the resulting dictionary no longer returns free
|
|
variables. (Free variables, in this case, are variables referred to in the
|
|
:keyword:`class` statement that aren't attributes of the class.)
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
Optimizations
|
|
-------------
|
|
|
|
* The :mod:`warnings` module has been rewritten in C. This makes
|
|
it possible to invoke warnings from the parser, and may also
|
|
make the interpreter's startup faster.
|
|
(Contributed by Neal Norwitz and Brett Cannon; :issue:`1631171`.)
|
|
|
|
* Type objects now have a cache of methods that can reduce
|
|
the amount of work required to find the correct method implementation
|
|
for a particular class; once cached, the interpreter doesn't need to
|
|
traverse base classes to figure out the right method to call.
|
|
The cache is cleared if a base class or the class itself is modified,
|
|
so the cache should remain correct even in the face of Python's dynamic
|
|
nature.
|
|
(Original optimization implemented by Armin Rigo, updated for
|
|
Python 2.6 by Kevin Jacobs; :issue:`1700288`.)
|
|
|
|
* Function calls that use keyword arguments
|
|
are significantly faster thanks to a patch that does a quick pointer
|
|
comparison, usually saving the time of a full string comparison.
|
|
(Contributed by Raymond Hettinger, after an initial implementation by
|
|
Antoine Pitrou; :issue:`1819`.)
|
|
|
|
* All of the functions in the :mod:`struct` module have been rewritten in
|
|
C, thanks to work at the Need For Speed sprint.
|
|
(Contributed by Raymond Hettinger.)
|
|
|
|
* Internally, a bit is now set in type objects to indicate some of the standard
|
|
built-in types. This speeds up checking if an object is a subclass of one of
|
|
these types. (Contributed by Neal Norwitz.)
|
|
|
|
* Unicode strings now use faster code for detecting
|
|
whitespace and line breaks; this speeds up the :meth:`split` method
|
|
by about 25% and :meth:`splitlines` by 35%.
|
|
(Contributed by Antoine Pitrou.) Memory usage is reduced
|
|
by using pymalloc for the Unicode string's data.
|
|
|
|
* The ``with`` statement now stores the :meth:`__exit__` method on the stack,
|
|
producing a small speedup. (Implemented by Jeffrey Yasskin.)
|
|
|
|
* To reduce memory usage, the garbage collector will now clear internal
|
|
free lists when garbage-collecting the highest generation of objects.
|
|
This may return memory to the OS sooner.
|
|
|
|
The net result of the 2.6 optimizations is that Python 2.6 runs the pystone
|
|
benchmark around XX% faster than Python 2.5.
|
|
|
|
.. ======================================================================
|
|
|
|
.. _new-26-interpreter:
|
|
|
|
Interpreter Changes
|
|
-------------------------------
|
|
|
|
Two command-line options have been reserved for use by other Python
|
|
implementations. The :option:`-J` switch has been reserved for use by
|
|
Jython for Jython-specific options, such as ones that are passed to
|
|
the underlying JVM. :option:`-X` has been reserved for options
|
|
specific to a particular implementation of Python such as CPython,
|
|
Jython, or IronPython. If either option is used with Python 2.6, the
|
|
interpreter will report that the option isn't currently used.
|
|
|
|
It's now possible to prevent Python from writing :file:`.pyc` or
|
|
:file:`.pyo` files on importing a module by supplying the :option:`-B`
|
|
switch to the Python interpreter, or by setting the
|
|
:envvar:`PYTHONDONTWRITEBYTECODE` environment variable before running
|
|
the interpreter. This setting is available to Python programs as the
|
|
``sys.dont_write_bytecode`` variable, and can be changed by Python
|
|
code to modify the interpreter's behaviour. (Contributed by Neal
|
|
Norwitz and Georg Brandl.)
|
|
|
|
The encoding used for standard input, output, and standard error can
|
|
be specified by setting the :envvar:`PYTHONIOENCODING` environment
|
|
variable before running the interpreter. The value should be a string
|
|
in the form ``**encoding**`` or ``**encoding**:**errorhandler**``.
|
|
The **encoding** part specifies the encoding's name, e.g. ``utf-8`` or
|
|
``latin-1``; the optional **errorhandler** part specifies
|
|
what to do with characters that can't be handled by the encoding,
|
|
and should be one of "error", "ignore", or "replace". (Contributed
|
|
by Martin von Loewis.)
|
|
|
|
.. ======================================================================
|
|
|
|
New, Improved, and Deprecated Modules
|
|
=====================================
|
|
|
|
As usual, Python's standard library received a number of enhancements and bug
|
|
fixes. Here's a partial list of the most notable changes, sorted alphabetically
|
|
by module name. Consult the :file:`Misc/NEWS` file in the source tree for a more
|
|
complete list of changes, or look through the Subversion logs for all the
|
|
details.
|
|
|
|
* (3.0-warning mode) Python 3.0 will feature a reorganized standard
|
|
library; many outdated modules are being dropped.
|
|
Python 2.6 running in 3.0-warning mode will warn about these modules
|
|
when they are imported.
|
|
|
|
The list of deprecated modules is:
|
|
:mod:`audiodev`,
|
|
:mod:`bgenlocations`,
|
|
:mod:`buildtools`,
|
|
:mod:`bundlebuilder`,
|
|
:mod:`Canvas`,
|
|
:mod:`compiler`,
|
|
:mod:`dircache`,
|
|
:mod:`dl`,
|
|
:mod:`fpformat`,
|
|
:mod:`gensuitemodule`,
|
|
:mod:`ihooks`,
|
|
:mod:`imageop`,
|
|
:mod:`imgfile`,
|
|
:mod:`linuxaudiodev`,
|
|
:mod:`mhlib`,
|
|
:mod:`mimetools`,
|
|
:mod:`multifile`,
|
|
:mod:`new`,
|
|
:mod:`popen2`,
|
|
:mod:`pure`,
|
|
:mod:`statvfs`,
|
|
:mod:`sunaudiodev`,
|
|
:mod:`test.testall`,
|
|
:mod:`toaiff`.
|
|
|
|
Various MacOS modules have been removed:
|
|
:mod:`_builtinSuites`,
|
|
:mod:`aepack`,
|
|
:mod:`aetools`,
|
|
:mod:`aetypes`,
|
|
:mod:`applesingle`,
|
|
:mod:`appletrawmain`,
|
|
:mod:`appletrunner`,
|
|
:mod:`argvemulator`,
|
|
:mod:`Audio_mac`,
|
|
:mod:`autoGIL`,
|
|
:mod:`Carbon`,
|
|
:mod:`cfmfile`,
|
|
:mod:`CodeWarrior`,
|
|
:mod:`ColorPicker`,
|
|
:mod:`EasyDialogs`,
|
|
:mod:`Explorer`,
|
|
:mod:`Finder`,
|
|
:mod:`FrameWork`,
|
|
:mod:`findertools`,
|
|
:mod:`ic`,
|
|
:mod:`icglue`,
|
|
:mod:`icopen`,
|
|
:mod:`macerrors`,
|
|
:mod:`MacOS`,
|
|
:mod:`macostools`,
|
|
:mod:`macresource`,
|
|
:mod:`MiniAEFrame`,
|
|
:mod:`Nav`,
|
|
:mod:`Netscape`,
|
|
:mod:`OSATerminology`,
|
|
:mod:`pimp`,
|
|
:mod:`PixMapWrapper`,
|
|
:mod:`StdSuites`,
|
|
:mod:`SystemEvents`,
|
|
:mod:`Terminal`,
|
|
:mod:`terminalcommand`.
|
|
|
|
A number of old IRIX-specific modules were deprecated:
|
|
:mod:`al` and :mod:`AL`,
|
|
:mod:`cd`,
|
|
:mod:`cddb`,
|
|
:mod:`cdplayer`,
|
|
:mod:`CL` and :mod:`cl`,
|
|
:mod:`DEVICE`,
|
|
:mod:`ERRNO`,
|
|
:mod:`FILE`,
|
|
:mod:`FL` and :mod:`fl`,
|
|
:mod:`flp`,
|
|
:mod:`fm`,
|
|
:mod:`GET`,
|
|
:mod:`GLWS`,
|
|
:mod:`GL` and :mod:`gl`,
|
|
:mod:`IN`,
|
|
:mod:`IOCTL`,
|
|
:mod:`jpeg`,
|
|
:mod:`panelparser`,
|
|
:mod:`readcd`,
|
|
:mod:`SV` and :mod:`sv`,
|
|
:mod:`torgb`,
|
|
:mod:`videoreader`,
|
|
:mod:`WAIT`.
|
|
|
|
* The :mod:`asyncore` and :mod:`asynchat` modules are
|
|
being actively maintained again, and a number of patches and bugfixes
|
|
were applied. (Maintained by Josiah Carlson; see :issue:`1736190` for
|
|
one patch.)
|
|
|
|
* The :mod:`bsddb.dbshelve` module now uses the highest pickling protocol
|
|
available, instead of restricting itself to protocol 1.
|
|
(Contributed by W. Barnes; :issue:`1551443`.)
|
|
|
|
* The :mod:`cgi` module will now read variables from the query string of an
|
|
HTTP POST request. This makes it possible to use form actions with
|
|
URLs such as "/cgi-bin/add.py?category=1". (Contributed by
|
|
Alexandre Fiori and Nubis; :issue:`1817`.)
|
|
|
|
* The :mod:`cmath` module underwent an extensive set of revisions,
|
|
thanks to Mark Dickinson and Christian Heimes, that added some new
|
|
features and greatly improved the accuracy of the computations.
|
|
|
|
Five new functions were added:
|
|
|
|
* :func:`polar` converts a complex number to polar form, returning
|
|
the modulus and argument of that complex number.
|
|
|
|
* :func:`rect` does the opposite, turning a (modulus, argument) pair
|
|
back into the corresponding complex number.
|
|
|
|
* :func:`phase` returns the phase or argument of a complex number.
|
|
|
|
* :func:`isnan` returns True if either
|
|
the real or imaginary part of its argument is a NaN.
|
|
|
|
* :func:`isinf` returns True if either the real or imaginary part of
|
|
its argument is infinite.
|
|
|
|
The revisions also improved the numerical soundness of the
|
|
:mod:`cmath` module. For all functions, the real and imaginary
|
|
parts of the results are accurate to within a few units of least
|
|
precision (ulps) whenever possible. See :issue:`1381` for the
|
|
details. The branch cuts for :func:`asinh`, :func:`atanh`: and
|
|
:func:`atan` have also been corrected.
|
|
|
|
The tests for the module have been greatly expanded; nearly 2000 new
|
|
test cases exercise the algebraic functions.
|
|
|
|
On IEEE 754 platforms, the :mod:`cmath` module now handles IEEE 754
|
|
special values and floating-point exceptions in a manner consistent
|
|
with Annex 'G' of the C99 standard.
|
|
|
|
* A new data type in the :mod:`collections` module: :class:`namedtuple(typename,
|
|
fieldnames)` is a factory function that creates subclasses of the standard tuple
|
|
whose fields are accessible by name as well as index. For example::
|
|
|
|
>>> var_type = collections.namedtuple('variable',
|
|
... 'id name type size')
|
|
# Names are separated by spaces or commas.
|
|
# 'id, name, type, size' would also work.
|
|
>>> var_type._fields
|
|
('id', 'name', 'type', 'size')
|
|
|
|
>>> var = var_type(1, 'frequency', 'int', 4)
|
|
>>> print var[0], var.id # Equivalent
|
|
1 1
|
|
>>> print var[2], var.type # Equivalent
|
|
int int
|
|
>>> var._asdict()
|
|
{'size': 4, 'type': 'int', 'id': 1, 'name': 'frequency'}
|
|
>>> v2 = var._replace(name='amplitude')
|
|
>>> v2
|
|
variable(id=1, name='amplitude', type='int', size=4)
|
|
|
|
Where the new :class:`namedtuple` type proved suitable, the standard
|
|
library has been modified to return them. For example,
|
|
the :meth:`Decimal.as_tuple` method now returns a named tuple with
|
|
:attr:`sign`, :attr:`digits`, and :attr:`exponent` fields.
|
|
|
|
(Contributed by Raymond Hettinger.)
|
|
|
|
* Another change to the :mod:`collections` module is that the
|
|
:class:`deque` type now supports an optional *maxlen* parameter;
|
|
if supplied, the deque's size will be restricted to no more
|
|
than *maxlen* items. Adding more items to a full deque causes
|
|
old items to be discarded.
|
|
|
|
::
|
|
|
|
>>> from collections import deque
|
|
>>> dq=deque(maxlen=3)
|
|
>>> dq
|
|
deque([], maxlen=3)
|
|
>>> dq.append(1) ; dq.append(2) ; dq.append(3)
|
|
>>> dq
|
|
deque([1, 2, 3], maxlen=3)
|
|
>>> dq.append(4)
|
|
>>> dq
|
|
deque([2, 3, 4], maxlen=3)
|
|
|
|
(Contributed by Raymond Hettinger.)
|
|
|
|
* A new method in the :mod:`curses` module: for a window, :meth:`chgat` changes
|
|
the display characters for a certain number of characters on a single line.
|
|
(Contributed by Fabian Kreutz.)
|
|
::
|
|
|
|
# Boldface text starting at y=0,x=21
|
|
# and affecting the rest of the line.
|
|
stdscr.chgat(0,21, curses.A_BOLD)
|
|
|
|
The :class:`Textbox` class in the :mod:`curses.textpad` module
|
|
now supports editing in insert mode as well as overwrite mode.
|
|
Insert mode is enabled by supplying a true value for the *insert_mode*
|
|
parameter when creating the :class:`Textbox` instance.
|
|
|
|
* The :mod:`datetime` module's :meth:`strftime` methods now support a
|
|
``%f`` format code that expands to the number of microseconds in the
|
|
object, zero-padded on
|
|
the left to six places. (Contributed by Skip Montanaro; :issue:`1158`.)
|
|
|
|
* The :mod:`decimal` module was updated to version 1.66 of
|
|
`the General Decimal Specification <http://www2.hursley.ibm.com/decimal/decarith.html>`__. New features
|
|
include some methods for some basic mathematical functions such as
|
|
:meth:`exp` and :meth:`log10`::
|
|
|
|
>>> Decimal(1).exp()
|
|
Decimal("2.718281828459045235360287471")
|
|
>>> Decimal("2.7182818").ln()
|
|
Decimal("0.9999999895305022877376682436")
|
|
>>> Decimal(1000).log10()
|
|
Decimal("3")
|
|
|
|
The :meth:`as_tuple` method of :class:`Decimal` objects now returns a
|
|
named tuple with :attr:`sign`, :attr:`digits`, and :attr:`exponent` fields.
|
|
|
|
(Implemented by Facundo Batista and Mark Dickinson. Named tuple
|
|
support added by Raymond Hettinger.)
|
|
|
|
* The :mod:`difflib` module's :class:`SequenceMatcher` class
|
|
now returns named tuples representing matches.
|
|
In addition to behaving like tuples, the returned values
|
|
also have :attr:`a`, :attr:`b`, and :attr:`size` attributes.
|
|
(Contributed by Raymond Hettinger.)
|
|
|
|
* An optional ``timeout`` parameter was added to the
|
|
:class:`ftplib.FTP` class constructor as well as the :meth:`connect`
|
|
method, specifying a timeout measured in seconds. (Added by Facundo
|
|
Batista.) Also, the :class:`FTP` class's
|
|
:meth:`storbinary` and :meth:`storlines`
|
|
now take an optional *callback* parameter that will be called with
|
|
each block of data after the data has been sent.
|
|
(Contributed by Phil Schwartz; :issue:`1221598`.)
|
|
|
|
* The :func:`reduce` built-in function is also available in the
|
|
:mod:`functools` module. In Python 3.0, the built-in is dropped and it's
|
|
only available from :mod:`functools`; currently there are no plans
|
|
to drop the built-in in the 2.x series. (Patched by
|
|
Christian Heimes; :issue:`1739906`.)
|
|
|
|
* When possible, the :mod:`getpass` module will now use
|
|
:file:`/dev/tty` (when available) to print
|
|
a prompting message and read the password, falling back to using
|
|
standard error and standard input. If the password may be echoed to
|
|
the terminal, a warning is printed before the prompt is displayed.
|
|
(Contributed by Gregory P. Smith.)
|
|
|
|
* The :func:`glob.glob` function can now return Unicode filenames if
|
|
a Unicode path was used and Unicode filenames are matched within the
|
|
directory. (:issue:`1001604`)
|
|
|
|
* The :mod:`gopherlib` module has been removed.
|
|
|
|
* A new function in the :mod:`heapq` module: ``merge(iter1, iter2, ...)``
|
|
takes any number of iterables that return data *in sorted
|
|
order*, and returns a new iterator that returns the contents of all
|
|
the iterators, also in sorted order. For example::
|
|
|
|
heapq.merge([1, 3, 5, 9], [2, 8, 16]) ->
|
|
[1, 2, 3, 5, 8, 9, 16]
|
|
|
|
Another new function, ``heappushpop(heap, item)``,
|
|
pushes *item* onto *heap*, then pops off and returns the smallest item.
|
|
This is more efficient than making a call to :func:`heappush` and then
|
|
:func:`heappop`.
|
|
|
|
:mod:`heapq` is now implemented to only use less-than comparison,
|
|
instead of the less-than-or-equal comparison it previously used.
|
|
This makes :mod:`heapq`'s usage of a type match that of the
|
|
:meth:`list.sort` method.
|
|
(Contributed by Raymond Hettinger.)
|
|
|
|
* An optional ``timeout`` parameter was added to the
|
|
:class:`httplib.HTTPConnection` and :class:`HTTPSConnection`
|
|
class constructors, specifying a timeout measured in seconds.
|
|
(Added by Facundo Batista.)
|
|
|
|
* Most of the :mod:`inspect` module's functions, such as
|
|
:func:`getmoduleinfo` and :func:`getargs`, now return named tuples.
|
|
In addition to behaving like tuples, the elements of the return value
|
|
can also be accessed as attributes.
|
|
(Contributed by Raymond Hettinger.)
|
|
|
|
Some new functions in the module include
|
|
:func:`isgenerator`, :func:`isgeneratorfunction`,
|
|
and :func:`isabstract`.
|
|
|
|
* The :mod:`itertools` module gained several new functions.
|
|
|
|
``izip_longest(iter1, iter2, ...[, fillvalue])`` makes tuples from
|
|
each of the elements; if some of the iterables are shorter than
|
|
others, the missing values are set to *fillvalue*. For example::
|
|
|
|
itertools.izip_longest([1,2,3], [1,2,3,4,5]) ->
|
|
[(1, 1), (2, 2), (3, 3), (None, 4), (None, 5)]
|
|
|
|
``product(iter1, iter2, ..., [repeat=N])`` returns the Cartesian product
|
|
of the supplied iterables, a set of tuples containing
|
|
every possible combination of the elements returned from each iterable. ::
|
|
|
|
itertools.product([1,2,3], [4,5,6]) ->
|
|
[(1, 4), (1, 5), (1, 6),
|
|
(2, 4), (2, 5), (2, 6),
|
|
(3, 4), (3, 5), (3, 6)]
|
|
|
|
The optional *repeat* keyword argument is used for taking the
|
|
product of an iterable or a set of iterables with themselves,
|
|
repeated *N* times. With a single iterable argument, *N*-tuples
|
|
are returned::
|
|
|
|
itertools.product([1,2], repeat=3)) ->
|
|
[(1, 1, 1), (1, 1, 2), (1, 2, 1), (1, 2, 2),
|
|
(2, 1, 1), (2, 1, 2), (2, 2, 1), (2, 2, 2)]
|
|
|
|
With two iterables, *2N*-tuples are returned. ::
|
|
|
|
itertools(product([1,2], [3,4], repeat=2) ->
|
|
[(1, 3, 1, 3), (1, 3, 1, 4), (1, 3, 2, 3), (1, 3, 2, 4),
|
|
(1, 4, 1, 3), (1, 4, 1, 4), (1, 4, 2, 3), (1, 4, 2, 4),
|
|
(2, 3, 1, 3), (2, 3, 1, 4), (2, 3, 2, 3), (2, 3, 2, 4),
|
|
(2, 4, 1, 3), (2, 4, 1, 4), (2, 4, 2, 3), (2, 4, 2, 4)]
|
|
|
|
``combinations(iterable, r)`` returns sub-sequences of length *r* from
|
|
the elements of *iterable*. ::
|
|
|
|
itertools.combinations('123', 2) ->
|
|
[('1', '2'), ('1', '3'), ('2', '3')]
|
|
|
|
itertools.combinations('123', 3) ->
|
|
[('1', '2', '3')]
|
|
|
|
itertools.combinations('1234', 3) ->
|
|
[('1', '2', '3'), ('1', '2', '4'), ('1', '3', '4'),
|
|
('2', '3', '4')]
|
|
|
|
``permutations(iter[, r])`` returns all the permutations of length *r* of
|
|
the iterable's elements. If *r* is not specified, it will default to the
|
|
number of elements produced by the iterable. ::
|
|
|
|
itertools.permutations([1,2,3,4], 2) ->
|
|
[(1, 2), (1, 3), (1, 4),
|
|
(2, 1), (2, 3), (2, 4),
|
|
(3, 1), (3, 2), (3, 4),
|
|
(4, 1), (4, 2), (4, 3)]
|
|
|
|
``itertools.chain(*iterables)`` is an existing function in
|
|
:mod:`itertools` that gained a new constructor in Python 2.6.
|
|
``itertools.chain.from_iterable(iterable)`` takes a single
|
|
iterable that should return other iterables. :func:`chain` will
|
|
then return all the elements of the first iterable, then
|
|
all the elements of the second, and so on. ::
|
|
|
|
chain.from_iterable([[1,2,3], [4,5,6]]) ->
|
|
[1, 2, 3, 4, 5, 6]
|
|
|
|
(All contributed by Raymond Hettinger.)
|
|
|
|
* The :mod:`logging` module's :class:`FileHandler` class
|
|
and its subclasses :class:`WatchedFileHandler`, :class:`RotatingFileHandler`,
|
|
and :class:`TimedRotatingFileHandler` now
|
|
have an optional *delay* parameter to its constructor. If *delay*
|
|
is true, opening of the log file is deferred until the first
|
|
:meth:`emit` call is made. (Contributed by Vinay Sajip.)
|
|
|
|
:class:`TimedRotatingFileHandler` also has a *utc* constructor
|
|
parameter. If the argument is true, UTC time will be used
|
|
in determining when midnight occurs and in generating filenames;
|
|
otherwise local time will be used.
|
|
|
|
* The :mod:`macfs` module has been removed. This in turn required the
|
|
:func:`macostools.touched` function to be removed because it depended on the
|
|
:mod:`macfs` module. (:issue:`1490190`)
|
|
|
|
* :class:`mmap` objects now have a :meth:`rfind` method that finds
|
|
a substring, beginning at the end of the string and searching
|
|
backwards. The :meth:`find` method
|
|
also gained an *end* parameter containing the index at which to stop
|
|
the forward search.
|
|
(Contributed by John Lenton.)
|
|
|
|
* The :mod:`operator` module gained a
|
|
:func:`methodcaller` function that takes a name and an optional
|
|
set of arguments, returning a callable that will call
|
|
the named function on any arguments passed to it. For example::
|
|
|
|
>>> # Equivalent to lambda s: s.replace('old', 'new')
|
|
>>> replacer = operator.methodcaller('replace', 'old', 'new')
|
|
>>> replacer('old wine in old bottles')
|
|
'new wine in new bottles'
|
|
|
|
(Contributed by Georg Brandl, after a suggestion by Gregory Petrosyan.)
|
|
|
|
The :func:`attrgetter` function now accepts dotted names and performs
|
|
the corresponding attribute lookups::
|
|
|
|
>>> inst_name = operator.attrgetter('__class__.__name__')
|
|
>>> inst_name('')
|
|
'str'
|
|
>>> inst_name(help)
|
|
'_Helper'
|
|
|
|
(Contributed by Georg Brandl, after a suggestion by Barry Warsaw.)
|
|
|
|
* New functions in the :mod:`os` module include
|
|
``fchmod(fd, mode)``, ``fchown(fd, uid, gid)``,
|
|
and ``lchmod(path, mode)``, on operating systems that support these
|
|
functions. :func:`fchmod` and :func:`fchown` let you change the mode
|
|
and ownership of an opened file, and :func:`lchmod` changes the mode
|
|
of a symlink.
|
|
|
|
(Contributed by Georg Brandl and Christian Heimes.)
|
|
|
|
* The :func:`os.walk` function now has a ``followlinks`` parameter. If
|
|
set to True, it will follow symlinks pointing to directories and
|
|
visit the directory's contents. For backward compatibility, the
|
|
parameter's default value is false. Note that the function can fall
|
|
into an infinite recursion if there's a symlink that points to a
|
|
parent directory. (:issue:`1273829`)
|
|
|
|
* The ``os.environ`` object's :meth:`clear` method will now unset the
|
|
environment variables using :func:`os.unsetenv` in addition to clearing
|
|
the object's keys. (Contributed by Martin Horcicka; :issue:`1181`.)
|
|
|
|
* In the :mod:`os.path` module, the :func:`splitext` function
|
|
has been changed to not split on leading period characters.
|
|
This produces better results when operating on Unix's dot-files.
|
|
For example, ``os.path.splitext('.ipython')``
|
|
now returns ``('.ipython', '')`` instead of ``('', '.ipython')``.
|
|
(:issue:`115886`)
|
|
|
|
A new function, :func:`relpath(path, start)` returns a relative path
|
|
from the ``start`` path, if it's supplied, or from the current
|
|
working directory to the destination ``path``. (Contributed by
|
|
Richard Barran; :issue:`1339796`.)
|
|
|
|
On Windows, :func:`os.path.expandvars` will now expand environment variables
|
|
in the form "%var%", and "~user" will be expanded into the
|
|
user's home directory path. (Contributed by Josiah Carlson;
|
|
:issue:`957650`.)
|
|
|
|
* The Python debugger provided by the :mod:`pdb` module
|
|
gained a new command: "run" restarts the Python program being debugged,
|
|
and can optionally take new command-line arguments for the program.
|
|
(Contributed by Rocky Bernstein; :issue:`1393667`.)
|
|
|
|
The :func:`post_mortem` function, used to enter debugging of a
|
|
traceback, will now use the traceback returned by :func:`sys.exc_info`
|
|
if no traceback is supplied. (Contributed by Facundo Batista;
|
|
:issue:`1106316`.)
|
|
|
|
* The :mod:`pickletools` module now has an :func:`optimize` function
|
|
that takes a string containing a pickle and removes some unused
|
|
opcodes, returning a shorter pickle that contains the same data structure.
|
|
(Contributed by Raymond Hettinger.)
|
|
|
|
* A :func:`get_data` function was added to the :mod:`pkgutil`
|
|
module that returns the contents of resource files included
|
|
with an installed Python package. For example::
|
|
|
|
>>> import pkgutil
|
|
>>> pkgutil.get_data('test', 'exception_hierarchy.txt')
|
|
'BaseException
|
|
+-- SystemExit
|
|
+-- KeyboardInterrupt
|
|
+-- GeneratorExit
|
|
+-- Exception
|
|
+-- StopIteration
|
|
+-- StandardError
|
|
...'
|
|
>>>
|
|
|
|
(Contributed by Paul Moore; :issue:`2439`.)
|
|
|
|
* New functions in the :mod:`posix` module: :func:`chflags` and :func:`lchflags`
|
|
are wrappers for the corresponding system calls (where they're available).
|
|
Constants for the flag values are defined in the :mod:`stat` module; some
|
|
possible values include :const:`UF_IMMUTABLE` to signal the file may not be
|
|
changed and :const:`UF_APPEND` to indicate that data can only be appended to the
|
|
file. (Contributed by M. Levinson.)
|
|
|
|
``os.closerange(*low*, *high*)`` efficiently closes all file descriptors
|
|
from *low* to *high*, ignoring any errors and not including *high* itself.
|
|
This function is now used by the :mod:`subprocess` module to make starting
|
|
processes faster. (Contributed by Georg Brandl; :issue:`1663329`.)
|
|
|
|
* The :mod:`pyexpat` module's :class:`Parser` objects now allow setting
|
|
their :attr:`buffer_size` attribute to change the size of the buffer
|
|
used to hold character data.
|
|
(Contributed by Achim Gaedke; :issue:`1137`.)
|
|
|
|
* The :mod:`Queue` module now provides queue classes that retrieve entries
|
|
in different orders. The :class:`PriorityQueue` class stores
|
|
queued items in a heap and retrieves them in priority order,
|
|
and :class:`LifoQueue` retrieves the most recently added entries first,
|
|
meaning that it behaves like a stack.
|
|
(Contributed by Raymond Hettinger.)
|
|
|
|
* The :mod:`random` module's :class:`Random` objects can
|
|
now be pickled on a 32-bit system and unpickled on a 64-bit
|
|
system, and vice versa. Unfortunately, this change also means
|
|
that Python 2.6's :class:`Random` objects can't be unpickled correctly
|
|
on earlier versions of Python.
|
|
(Contributed by Shawn Ligocki; :issue:`1727780`.)
|
|
|
|
The new ``triangular(low, high, mode)`` function returns random
|
|
numbers following a triangular distribution. The returned values
|
|
are between *low* and *high*, not including *high* itself, and
|
|
with *mode* as the mode, the most frequently occurring value
|
|
in the distribution. (Contributed by Wladmir van der Laan and
|
|
Raymond Hettinger; :issue:`1681432`.)
|
|
|
|
* Long regular expression searches carried out by the :mod:`re`
|
|
module will now check for signals being delivered, so especially
|
|
time-consuming searches can now be interrupted.
|
|
(Contributed by Josh Hoyt and Ralf Schmitt; :issue:`846388`.)
|
|
|
|
* The :mod:`rgbimg` module has been removed.
|
|
|
|
* The :mod:`rlcompleter` module's :meth:`Completer.complete()` method
|
|
will now ignore exceptions triggered while evaluating a name.
|
|
(Fixed by Lorenz Quack; :issue:`2250`.)
|
|
|
|
* The :mod:`sched` module's :class:`scheduler` instances now
|
|
have a read-only :attr:`queue` attribute that returns the
|
|
contents of the scheduler's queue, represented as a list of
|
|
named tuples with the fields ``(time, priority, action, argument)``.
|
|
(Contributed by Raymond Hettinger; :issue:`1861`.)
|
|
|
|
* The :mod:`select` module now has wrapper functions
|
|
for the Linux :cfunc:`epoll` and BSD :cfunc:`kqueue` system calls.
|
|
Also, a :meth:`modify` method was added to the existing :class:`poll`
|
|
objects; ``pollobj.modify(fd, eventmask)`` takes a file descriptor
|
|
or file object and an event mask,
|
|
|
|
(Contributed by Christian Heimes; :issue:`1657`.)
|
|
|
|
* The :mod:`sets` module has been deprecated; it's better to
|
|
use the built-in :class:`set` and :class:`frozenset` types.
|
|
|
|
* The :func:`shutil.copytree` function now has an optional **ignore** argument
|
|
that takes a callable object. This callable will receive each directory path
|
|
and a list of the directory's contents, and returns a list of names that
|
|
will be ignored, not copied.
|
|
|
|
The :mod:`shutil` module also provides an :func:`ignore_patterns`
|
|
function for use with this new parameter.
|
|
:func:`ignore_patterns` takes an arbitrary number of glob-style patterns
|
|
and will ignore any files and directories that match this pattern.
|
|
The following example copies a directory tree, but skip both SVN's internal
|
|
:file:`.svn` directories and Emacs backup
|
|
files, which have names ending with '~'::
|
|
|
|
shutil.copytree('Doc/library', '/tmp/library',
|
|
ignore=shutil.ignore_patterns('*~', '.svn'))
|
|
|
|
(Contributed by Tarek Ziadé; :issue:`2663`.)
|
|
|
|
* Integrating signal handling with GUI handling event loops
|
|
like those used by Tkinter or GTk+ has long been a problem; most
|
|
software ends up polling, waking up every fraction of a second.
|
|
The :mod:`signal` module can now make this more efficient.
|
|
Calling ``signal.set_wakeup_fd(fd)`` sets a file descriptor
|
|
to be used; when a signal is received, a byte is written to that
|
|
file descriptor. There's also a C-level function,
|
|
:cfunc:`PySignal_SetWakeupFd`, for setting the descriptor.
|
|
|
|
Event loops will use this by opening a pipe to create two descriptors,
|
|
one for reading and one for writing. The writable descriptor
|
|
will be passed to :func:`set_wakeup_fd`, and the readable descriptor
|
|
will be added to the list of descriptors monitored by the event loop via
|
|
:cfunc:`select` or :cfunc:`poll`.
|
|
On receiving a signal, a byte will be written and the main event loop
|
|
will be woken up, without the need to poll.
|
|
|
|
(Contributed by Adam Olsen; :issue:`1583`.)
|
|
|
|
The :func:`siginterrupt` function is now available from Python code,
|
|
and allows changing whether signals can interrupt system calls or not.
|
|
(Contributed by Ralf Schmitt.)
|
|
|
|
The :func:`setitimer` and :func:`getitimer` functions have also been
|
|
added on systems that support these system calls. :func:`setitimer`
|
|
allows setting interval timers that will cause a signal to be
|
|
delivered to the process after a specified time, measured in
|
|
wall-clock time, consumed process time, or combined process+system
|
|
time. (Contributed by Guilherme Polo; :issue:`2240`.)
|
|
|
|
* The :mod:`smtplib` module now supports SMTP over SSL thanks to the
|
|
addition of the :class:`SMTP_SSL` class. This class supports an
|
|
interface identical to the existing :class:`SMTP` class. Both
|
|
class constructors also have an optional ``timeout`` parameter
|
|
that specifies a timeout for the initial connection attempt, measured in
|
|
seconds.
|
|
|
|
An implementation of the LMTP protocol (:rfc:`2033`) was also added to
|
|
the module. LMTP is used in place of SMTP when transferring e-mail
|
|
between agents that don't manage a mail queue.
|
|
|
|
(SMTP over SSL contributed by Monty Taylor; timeout parameter
|
|
added by Facundo Batista; LMTP implemented by Leif
|
|
Hedstrom; :issue:`957003`.)
|
|
|
|
* In the :mod:`smtplib` module, SMTP.starttls() now complies with :rfc:`3207`
|
|
and forgets any knowledge obtained from the server not obtained from
|
|
the TLS negotiation itself. (Patch contributed by Bill Fenner;
|
|
:issue:`829951`.)
|
|
|
|
* The :mod:`socket` module now supports TIPC (http://tipc.sf.net),
|
|
a high-performance non-IP-based protocol designed for use in clustered
|
|
environments. TIPC addresses are 4- or 5-tuples.
|
|
(Contributed by Alberto Bertogli; :issue:`1646`.)
|
|
|
|
A new function, :func:`create_connection`, takes an address
|
|
and connects to it using an optional timeout value, returning
|
|
the connected socket object.
|
|
|
|
* The base classes in the :mod:`SocketServer` module now support
|
|
calling a :meth:`handle_timeout` method after a span of inactivity
|
|
specified by the server's :attr:`timeout` attribute. (Contributed
|
|
by Michael Pomraning.) The :meth:`serve_forever` method
|
|
now takes an optional poll interval measured in seconds,
|
|
controlling how often the server will check for a shutdown request.
|
|
(Contributed by Pedro Werneck and Jeffrey Yasskin;
|
|
:issue:`742598`, :issue:`1193577`.)
|
|
|
|
* The :mod:`struct` module now supports the C99 :ctype:`_Bool` type,
|
|
using the format character ``'?'``.
|
|
(Contributed by David Remahl.)
|
|
|
|
* The :class:`Popen` objects provided by the :mod:`subprocess` module
|
|
now have :meth:`terminate`, :meth:`kill`, and :meth:`send_signal` methods.
|
|
On Windows, :meth:`send_signal` only supports the :const:`SIGTERM`
|
|
signal, and all these methods are aliases for the Win32 API function
|
|
:cfunc:`TerminateProcess`.
|
|
(Contributed by Christian Heimes.)
|
|
|
|
* A new variable in the :mod:`sys` module,
|
|
:attr:`float_info`, is an object
|
|
containing information about the platform's floating-point support
|
|
derived from the :file:`float.h` file. Attributes of this object
|
|
include
|
|
:attr:`mant_dig` (number of digits in the mantissa), :attr:`epsilon`
|
|
(smallest difference between 1.0 and the next largest value
|
|
representable), and several others. (Contributed by Christian Heimes;
|
|
:issue:`1534`.)
|
|
|
|
Another new variable, :attr:`dont_write_bytecode`, controls whether Python
|
|
writes any :file:`.pyc` or :file:`.pyo` files on importing a module.
|
|
If this variable is true, the compiled files are not written. The
|
|
variable is initially set on start-up by supplying the :option:`-B`
|
|
switch to the Python interpreter, or by setting the
|
|
:envvar:`PYTHONDONTWRITEBYTECODE` environment variable before
|
|
running the interpreter. Python code can subsequently
|
|
change the value of this variable to control whether bytecode files
|
|
are written or not.
|
|
(Contributed by Neal Norwitz and Georg Brandl.)
|
|
|
|
Information about the command-line arguments supplied to the Python
|
|
interpreter is available by reading attributes of a named
|
|
tuple available as ``sys.flags``. For example, the :attr:`verbose`
|
|
attribute is true if Python
|
|
was executed in verbose mode, :attr:`debug` is true in debugging mode, etc.
|
|
These attributes are all read-only.
|
|
(Contributed by Christian Heimes.)
|
|
|
|
A new function, :func:`getsizeof`, takes a Python object and returns
|
|
the amount of memory used by the object, measured in bytes. Built-in
|
|
objects return correct results; third-party extensions may not,
|
|
but can define a :meth:`__sizeof__` method to return the
|
|
object's size.
|
|
(Contributed by Robert Schuppenies; :issue:`2898`.)
|
|
|
|
It's now possible to determine the current profiler and tracer functions
|
|
by calling :func:`sys.getprofile` and :func:`sys.gettrace`.
|
|
(Contributed by Georg Brandl; :issue:`1648`.)
|
|
|
|
* The :mod:`tarfile` module now supports POSIX.1-2001 (pax) and
|
|
POSIX.1-1988 (ustar) format tarfiles, in addition to the GNU tar
|
|
format that was already supported. The default format
|
|
is GNU tar; specify the ``format`` parameter to open a file
|
|
using a different format::
|
|
|
|
tar = tarfile.open("output.tar", "w", format=tarfile.PAX_FORMAT)
|
|
|
|
The new ``errors`` parameter lets you specify an error handling
|
|
scheme for character conversions: the three standard ways Python can
|
|
handle errors ``'strict'``, ``'ignore'``, ``'replace'`` , or the
|
|
special value ``'utf-8'``, which replaces bad characters with their
|
|
UTF-8 representation. Character conversions occur because the PAX
|
|
format supports Unicode filenames, defaulting to UTF-8 encoding.
|
|
|
|
The :meth:`TarFile.add` method now accepts a ``exclude`` argument that's
|
|
a function that can be used to exclude certain filenames from
|
|
an archive.
|
|
The function must take a filename and return true if the file
|
|
should be excluded or false if it should be archived.
|
|
The function is applied to both the name initially passed to :meth:`add`
|
|
and to the names of files in recursively-added directories.
|
|
|
|
(All changes contributed by Lars Gustäbel).
|
|
|
|
* An optional ``timeout`` parameter was added to the
|
|
:class:`telnetlib.Telnet` class constructor, specifying a timeout
|
|
measured in seconds. (Added by Facundo Batista.)
|
|
|
|
* The :class:`tempfile.NamedTemporaryFile` class usually deletes
|
|
the temporary file it created when the file is closed. This
|
|
behaviour can now be changed by passing ``delete=False`` to the
|
|
constructor. (Contributed by Damien Miller; :issue:`1537850`.)
|
|
|
|
A new class, :class:`SpooledTemporaryFile`, behaves like
|
|
a temporary file but stores its data in memory until a maximum size is
|
|
exceeded. On reaching that limit, the contents will be written to
|
|
an on-disk temporary file. (Contributed by Dustin J. Mitchell.)
|
|
|
|
The :class:`NamedTemporaryFile` and :class:`SpooledTemporaryFile` classes
|
|
both work as context managers, so you can write
|
|
``with tempfile.NamedTemporaryFile() as tmp: ...``.
|
|
(Contributed by Alexander Belopolsky; :issue:`2021`.)
|
|
|
|
* The :mod:`test.test_support` module now contains a
|
|
:func:`EnvironmentVarGuard`
|
|
context manager that supports temporarily changing environment variables and
|
|
automatically restores them to their old values.
|
|
|
|
Another context manager, :class:`TransientResource`, can surround calls
|
|
to resources that may or may not be available; it will catch and
|
|
ignore a specified list of exceptions. For example,
|
|
a network test may ignore certain failures when connecting to an
|
|
external web site::
|
|
|
|
with test_support.TransientResource(IOError, errno=errno.ETIMEDOUT):
|
|
f = urllib.urlopen('https://sf.net')
|
|
...
|
|
|
|
(Contributed by Brett Cannon.)
|
|
|
|
* The :mod:`textwrap` module can now preserve existing whitespace
|
|
at the beginnings and ends of the newly-created lines
|
|
by specifying ``drop_whitespace=False``
|
|
as an argument::
|
|
|
|
>>> S = """This sentence has a bunch of extra whitespace."""
|
|
>>> print textwrap.fill(S, width=15)
|
|
This sentence
|
|
has a bunch
|
|
of extra
|
|
whitespace.
|
|
>>> print textwrap.fill(S, drop_whitespace=False, width=15)
|
|
This sentence
|
|
has a bunch
|
|
of extra
|
|
whitespace.
|
|
>>>
|
|
|
|
(Contributed by Dwayne Bailey; :issue:`1581073`.)
|
|
|
|
* The :mod:`threading` module's :class:`Thread` objects
|
|
gained a :meth:`getIdent` method that returns the thread's
|
|
identifier, a nonzero integer. (Contributed by Gregory P. Smith;
|
|
:issue:`2871`.)
|
|
|
|
* The :mod:`timeit` module now accepts callables as well as strings
|
|
for the statement being timed and for the setup code.
|
|
Two convenience functions were added for creating
|
|
:class:`Timer` instances:
|
|
``repeat(stmt, setup, time, repeat, number)`` and
|
|
``timeit(stmt, setup, time, number)`` create an instance and call
|
|
the corresponding method. (Contributed by Erik Demaine;
|
|
:issue:`1533909`.)
|
|
|
|
* The :mod:`Tkinter` module now accepts lists and tuples for options,
|
|
separating the elements by spaces before passing the resulting value to
|
|
Tcl/Tk.
|
|
(Contributed by Guilherme Polo; :issue:`2906`.)
|
|
|
|
* The :mod:`turtle` module for turtle graphics was greatly enhanced by
|
|
Gregor Lingl. New features in the module include:
|
|
|
|
* Better animation of turtle movement and rotation.
|
|
* Control over turtle movement using the new delay(),
|
|
tracer(), and speed() methods.
|
|
* The ability to set new shapes for the turtle, and to
|
|
define a new coordinate system.
|
|
* Turtles now have an undo() method that can roll back actions.
|
|
* Simple support for reacting to input events such as mouse and keyboard
|
|
activity, making it possible to write simple games.
|
|
* A :file:`turtle.cfg` file can be used to customize the starting appearance
|
|
of the turtle's screen.
|
|
* The module's docstrings can be replaced by new docstrings that have been
|
|
translated into another language.
|
|
|
|
(:issue:`1513695`)
|
|
|
|
* An optional ``timeout`` parameter was added to the
|
|
:func:`urllib.urlopen` function and the
|
|
:class:`urllib.ftpwrapper` class constructor, as well as the
|
|
:func:`urllib2.urlopen` function. The parameter specifies a timeout
|
|
measured in seconds. For example::
|
|
|
|
>>> u = urllib2.urlopen("http://slow.example.com", timeout=3)
|
|
Traceback (most recent call last):
|
|
...
|
|
urllib2.URLError: <urlopen error timed out>
|
|
>>>
|
|
|
|
(Added by Facundo Batista.)
|
|
|
|
* The :mod:`warnings` module's :func:`formatwarning` and :func:`showwarning`
|
|
gained an optional *line* argument that can be used to supply the
|
|
line of source code. (Added as part of :issue:`1631171`, which re-implemented
|
|
part of the :mod:`warnings` module in C code.)
|
|
|
|
* The XML-RPC :class:`SimpleXMLRPCServer` and :class:`DocXMLRPCServer`
|
|
classes can now be prevented from immediately opening and binding to
|
|
their socket by passing True as the ``bind_and_activate``
|
|
constructor parameter. This can be used to modify the instance's
|
|
:attr:`allow_reuse_address` attribute before calling the
|
|
:meth:`server_bind` and :meth:`server_activate` methods to
|
|
open the socket and begin listening for connections.
|
|
(Contributed by Peter Parente; :issue:`1599845`.)
|
|
|
|
:class:`SimpleXMLRPCServer` also has a :attr:`_send_traceback_header`
|
|
attribute; if true, the exception and formatted traceback are returned
|
|
as HTTP headers "X-Exception" and "X-Traceback". This feature is
|
|
for debugging purposes only and should not be used on production servers
|
|
because the tracebacks could possibly reveal passwords or other sensitive
|
|
information. (Contributed by Alan McIntyre as part of his
|
|
project for Google's Summer of Code 2007.)
|
|
|
|
* The :mod:`xmlrpclib` module no longer automatically converts
|
|
:class:`datetime.date` and :class:`datetime.time` to the
|
|
:class:`xmlrpclib.DateTime` type; the conversion semantics were
|
|
not necessarily correct for all applications. Code using
|
|
:mod:`xmlrpclib` should convert :class:`date` and :class:`time`
|
|
instances. (:issue:`1330538`) The code can also handle
|
|
dates before 1900 (contributed by Ralf Schmitt; :issue:`2014`)
|
|
and 64-bit integers represented by using ``<i8>`` in XML-RPC responses
|
|
(contributed by Riku Lindblad; :issue:`2985`).
|
|
|
|
* The :mod:`zipfile` module's :class:`ZipFile` class now has
|
|
:meth:`extract` and :meth:`extractall` methods that will unpack
|
|
a single file or all the files in the archive to the current directory, or
|
|
to a specified directory::
|
|
|
|
z = zipfile.ZipFile('python-251.zip')
|
|
|
|
# Unpack a single file, writing it relative to the /tmp directory.
|
|
z.extract('Python/sysmodule.c', '/tmp')
|
|
|
|
# Unpack all the files in the archive.
|
|
z.extractall()
|
|
|
|
(Contributed by Alan McIntyre; :issue:`467924`.)
|
|
|
|
The :meth:`open`, :meth:`read` and :meth:`extract` methods can now
|
|
take either a filename or a :class:`ZipInfo` object. This is useful when an
|
|
archive accidentally contains a duplicated filename.
|
|
(Contributed by Graham Horler; :issue:`1775025`.)
|
|
|
|
Finally, :mod:`zipfile` now supports using Unicode filenames
|
|
for archived files. (Contributed by Alexey Borzenkov; :issue:`1734346`.)
|
|
|
|
.. ======================================================================
|
|
.. whole new modules get described in subsections here
|
|
|
|
The :mod:`ast` module
|
|
----------------------
|
|
|
|
The :mod:`ast` module provides an Abstract Syntax Tree representation
|
|
of Python code. For Python 2.6, Armin Ronacher contributed a set of
|
|
helper functions that perform various common tasks. These will be useful
|
|
for HTML templating packages, code analyzers, and similar tools that
|
|
process Python code.
|
|
|
|
The :func:`parse` function takes an expression and returns an AST.
|
|
The :func:`dump` function outputs a representation of a tree, suitable
|
|
for debugging::
|
|
|
|
import ast
|
|
|
|
t = ast.parse("""
|
|
d = {}
|
|
for i in 'abcdefghijklm':
|
|
d[i + i] = ord(i) - ord('a') + 1
|
|
print d
|
|
""")
|
|
print ast.dump(t)
|
|
|
|
This outputs::
|
|
|
|
Module(body=[Assign(targets=[Name(id='d', ctx=Store())],
|
|
value=Dict(keys=[], values=[])), For(target=Name(id='i',
|
|
ctx=Store()), iter=Str(s='abcdefghijklm'),
|
|
body=[Assign(targets=[Subscript(value=Name(id='d', ctx=Load()),
|
|
slice=Index(value=BinOp(left=Name(id='i', ctx=Load()), op=Add(),
|
|
right=Name(id='i', ctx=Load()))), ctx=Store())],
|
|
value=BinOp(left=BinOp(left=Call(func=Name(id='ord', ctx=Load()),
|
|
args=[Name(id='i', ctx=Load())], keywords=[], starargs=None,
|
|
kwargs=None), op=Sub(), right=Call(func=Name(id='ord',
|
|
ctx=Load()), args=[Str(s='a')], keywords=[], starargs=None,
|
|
kwargs=None)), op=Add(), right=Num(n=1)))], orelse=[]),
|
|
Print(dest=None, values=[Name(id='d', ctx=Load())], nl=True)])
|
|
|
|
The :func:`literal_eval` method takes a string or an AST
|
|
representing a literal expression, one that contains a Python
|
|
expression containing only strings, numbers, dictionaries, etc. but no
|
|
statements or function calls, and returns the resulting value. If you
|
|
need to unserialize an expression but need to worry about security
|
|
and can't risk using an :func:`eval` call, :func:`literal_eval` will
|
|
handle it safely::
|
|
|
|
>>> literal = '("a", "b", {2:4, 3:8, 1:2})'
|
|
>>> print ast.literal_eval(literal)
|
|
('a', 'b', {1: 2, 2: 4, 3: 8})
|
|
>>> print ast.literal_eval('"a" + "b"')
|
|
Traceback (most recent call last):
|
|
...
|
|
ValueError: malformed string
|
|
|
|
The module also includes :class:`NodeVisitor` and
|
|
:class:`NodeTransformer` classes for traversing and modifying an AST,
|
|
and functions for common transformations such as changing line
|
|
numbers.
|
|
|
|
.. ======================================================================
|
|
|
|
The :mod:`future_builtins` module
|
|
--------------------------------------
|
|
|
|
Python 3.0 makes various changes to the repertoire of built-in
|
|
functions, and most of the changes can't be introduced in the Python
|
|
2.x series because they would break compatibility.
|
|
The :mod:`future_builtins` module provides versions
|
|
of these built-in functions that can be imported when writing
|
|
3.0-compatible code.
|
|
|
|
The functions in this module currently include:
|
|
|
|
* ``ascii(**obj**)``: equivalent to :func:`repr`. In Python 3.0,
|
|
:func:`repr` will return a Unicode string, while :func:`ascii` will
|
|
return a pure ASCII bytestring.
|
|
|
|
* ``filter(**predicate**, **iterable**)``,
|
|
``map(**func**, **iterable1**, ...)``: the 3.0 versions
|
|
return iterators, differing from the 2.x built-ins that return lists.
|
|
|
|
* ``hex(**value**)``, ``oct(**value**)``: instead of calling the
|
|
:meth:`__hex__` or :meth:`__oct__` methods, these versions will
|
|
call the :meth:`__index__` method and convert the result to hexadecimal
|
|
or octal.
|
|
|
|
.. ======================================================================
|
|
|
|
The :mod:`json` module
|
|
----------------------
|
|
|
|
The new :mod:`json` module supports the encoding and decoding of Python types in
|
|
JSON (Javascript Object Notation). JSON is a lightweight interchange format
|
|
often used in web applications. For more information about JSON, see
|
|
http://www.json.org.
|
|
|
|
:mod:`json` comes with support for decoding and encoding most builtin Python
|
|
types. The following example encodes and decodes a dictionary::
|
|
|
|
>>> import json
|
|
>>> data = {"spam" : "foo", "parrot" : 42}
|
|
>>> in_json = json.dumps(data) # Encode the data
|
|
>>> in_json
|
|
'{"parrot": 42, "spam": "foo"}'
|
|
>>> json.loads(in_json) # Decode into a Python object
|
|
{"spam" : "foo", "parrot" : 42}
|
|
|
|
It is also possible to write your own decoders and encoders to support more
|
|
types. Pretty-printing of the JSON strings is also supported.
|
|
|
|
:mod:`json` (originally called simplejson) was written by Bob Ippolito.
|
|
|
|
|
|
.. ======================================================================
|
|
|
|
plistlib: A Property-List Parser
|
|
--------------------------------------------------
|
|
|
|
A commonly-used format on MacOS X is the ``.plist`` format,
|
|
which stores basic data types (numbers, strings, lists,
|
|
and dictionaries) and serializes them into an XML-based format.
|
|
(It's a lot like the XML-RPC serialization of data types.)
|
|
|
|
Despite being primarily used on MacOS X, the format
|
|
has nothing Mac-specific about it and the Python implementation works
|
|
on any platform that Python supports, so the :mod:`plistlib` module
|
|
has been promoted to the standard library.
|
|
|
|
Using the module is simple::
|
|
|
|
import sys
|
|
import plistlib
|
|
import datetime
|
|
|
|
# Create data structure
|
|
data_struct = dict(lastAccessed=datetime.datetime.now(),
|
|
version=1,
|
|
categories=('Personal', 'Shared', 'Private'))
|
|
|
|
# Create string containing XML.
|
|
plist_str = plistlib.writePlistToString(data_struct)
|
|
new_struct = plistlib.readPlistFromString(plist_str)
|
|
print data_struct
|
|
print new_struct
|
|
|
|
# Write data structure to a file and read it back.
|
|
plistlib.writePlist(data_struct, '/tmp/customizations.plist')
|
|
new_struct = plistlib.readPlist('/tmp/customizations.plist')
|
|
|
|
# read/writePlist accepts file-like objects as well as paths.
|
|
plistlib.writePlist(data_struct, sys.stdout)
|
|
|
|
.. ======================================================================
|
|
|
|
ctypes Enhancements
|
|
--------------------------------------------------
|
|
|
|
Thomas Heller continued to maintain and enhance the
|
|
:mod:`ctypes` module.
|
|
|
|
:mod:`ctypes` now supports a :class:`c_bool` datatype
|
|
that represents the C99 ``bool`` type. (Contributed by David Remahl;
|
|
:issue:`1649190`.)
|
|
|
|
The :mod:`ctypes` string, buffer and array types have improved
|
|
support for extended slicing syntax,
|
|
where various combinations of ``(start, stop, step)`` are supplied.
|
|
(Implemented by Thomas Wouters.)
|
|
|
|
.. Revision 57769
|
|
|
|
A new calling convention tells :mod:`ctypes` to clear the ``errno`` or
|
|
Win32 LastError variables at the outset of each wrapped call.
|
|
(Implemented by Thomas Heller; :issue:`1798`.)
|
|
|
|
For the Unix ``errno`` variable: when creating a wrapped function,
|
|
you can supply ``use_errno=True`` as a keyword parameter
|
|
to the :func:`DLL` function
|
|
and then call the module-level methods :meth:`set_errno`
|
|
and :meth:`get_errno` to set and retrieve the error value.
|
|
|
|
The Win32 LastError variable is supported similarly by
|
|
the :func:`DLL`, :func:`OleDLL`, and :func:`WinDLL` functions.
|
|
You supply ``use_last_error=True`` as a keyword parameter
|
|
and then call the module-level methods :meth:`set_last_error`
|
|
and :meth:`get_last_error`.
|
|
|
|
The :func:`byref` function, used to retrieve a pointer to a ctypes
|
|
instance, now has an optional **offset** parameter that is a byte
|
|
count that will be added to the returned pointer.
|
|
|
|
.. ======================================================================
|
|
|
|
Improved SSL Support
|
|
--------------------------------------------------
|
|
|
|
Bill Janssen made extensive improvements to Python 2.6's support for
|
|
the Secure Sockets Layer by adding a new module, :mod:`ssl`, on top of
|
|
the `OpenSSL <http://www.openssl.org/>`__ library. This new module
|
|
provides more control over the protocol negotiated, the X.509
|
|
certificates used, and has better support for writing SSL servers (as
|
|
opposed to clients) in Python. The existing SSL support in the
|
|
:mod:`socket` module hasn't been removed and continues to work,
|
|
though it will be removed in Python 3.0.
|
|
|
|
To use the new module, first you must create a TCP connection in the
|
|
usual way and then pass it to the :func:`ssl.wrap_socket` function.
|
|
It's possible to specify whether a certificate is required, and to
|
|
obtain certificate info by calling the :meth:`getpeercert` method.
|
|
|
|
.. seealso::
|
|
|
|
The documentation for the :mod:`ssl` module.
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
Build and C API Changes
|
|
=======================
|
|
|
|
Changes to Python's build process and to the C API include:
|
|
|
|
* Python 2.6 can be built with Microsoft Visual Studio 2008.
|
|
See the :file:`PCbuild9` directory for the build files.
|
|
(Implemented by Christian Heimes.)
|
|
|
|
* On MacOS X, Python 2.6 can be compiled as a 4-way universal build.
|
|
The :program:`configure` script
|
|
can take a :option:`--with-universal-archs=[32-bit|64-bit|all]`
|
|
switch, controlling whether the binaries are built for 32-bit
|
|
architectures (x86, PowerPC), 64-bit (x86-64 and PPC-64), or both.
|
|
(Contributed by Ronald Oussoren.)
|
|
|
|
* Python now can only be compiled with C89 compilers (after 19
|
|
years!). This means that the Python source tree can now drop its
|
|
own implementations of :cfunc:`memmove` and :cfunc:`strerror`, which
|
|
are in the C89 standard library.
|
|
|
|
* The BerkeleyDB module now has a C API object, available as
|
|
``bsddb.db.api``. This object can be used by other C extensions
|
|
that wish to use the :mod:`bsddb` module for their own purposes.
|
|
(Contributed by Duncan Grisby; :issue:`1551895`.)
|
|
|
|
* The new buffer interface, previously described in
|
|
`the PEP 3118 section <#pep-3118-revised-buffer-protocol>`__,
|
|
adds :cfunc:`PyObject_GetBuffer` and :cfunc:`PyBuffer_Release`,
|
|
as well as a few other functions.
|
|
|
|
* Python's use of the C stdio library is now thread-safe, or at least
|
|
as thread-safe as the underlying library is. A long-standing potential
|
|
bug occurred if one thread closed a file object while another thread
|
|
was reading from or writing to the object. In 2.6 file objects
|
|
have a reference count, manipulated by the
|
|
:cfunc:`PyFile_IncUseCount` and :cfunc:`PyFile_DecUseCount`
|
|
functions. File objects can't be closed unless the reference count
|
|
is zero. :cfunc:`PyFile_IncUseCount` should be called while the GIL
|
|
is still held, before carrying out an I/O operation using the
|
|
``FILE *`` pointer, and :cfunc:`PyFile_DecUseCount` should be called
|
|
immediately after the GIL is re-acquired.
|
|
(Contributed by Antoine Pitrou and Gregory P. Smith.)
|
|
|
|
* Importing modules simultaneously in two different threads no longer
|
|
deadlocks; it will now raise an :exc:`ImportError`. A new API
|
|
function, :cfunc:`PyImport_ImportModuleNoBlock`, will look for a
|
|
module in ``sys.modules`` first, then try to import it after
|
|
acquiring an import lock. If the import lock is held by another
|
|
thread, the :exc:`ImportError` is raised.
|
|
(Contributed by Christian Heimes.)
|
|
|
|
* Several functions return information about the platform's
|
|
floating-point support. :cfunc:`PyFloat_GetMax` returns
|
|
the maximum representable floating point value,
|
|
and :cfunc:`PyFloat_GetMin` returns the minimum
|
|
positive value. :cfunc:`PyFloat_GetInfo` returns a dictionary
|
|
containing more information from the :file:`float.h` file, such as
|
|
``"mant_dig"`` (number of digits in the mantissa), ``"epsilon"``
|
|
(smallest difference between 1.0 and the next largest value
|
|
representable), and several others.
|
|
(Contributed by Christian Heimes; :issue:`1534`.)
|
|
|
|
* C functions and methods that use
|
|
:cfunc:`PyComplex_AsCComplex` will now accept arguments that
|
|
have a :meth:`__complex__` method. In particular, the functions in the
|
|
:mod:`cmath` module will now accept objects with this method.
|
|
This is a backport of a Python 3.0 change.
|
|
(Contributed by Mark Dickinson; :issue:`1675423`.)
|
|
|
|
* Python's C API now includes two functions for case-insensitive string
|
|
comparisons, ``PyOS_stricmp(char*, char*)``
|
|
and ``PyOS_strnicmp(char*, char*, Py_ssize_t)``.
|
|
(Contributed by Christian Heimes; :issue:`1635`.)
|
|
|
|
* Many C extensions define their own little macro for adding
|
|
integers and strings to the module's dictionary in the
|
|
``init*`` function. Python 2.6 finally defines standard macros
|
|
for adding values to a module, :cmacro:`PyModule_AddStringMacro`
|
|
and :cmacro:`PyModule_AddIntMacro()`. (Contributed by
|
|
Christian Heimes.)
|
|
|
|
* Some macros were renamed in both 3.0 and 2.6 to make it clearer that
|
|
they are macros,
|
|
not functions. :cmacro:`Py_Size()` became :cmacro:`Py_SIZE()`,
|
|
:cmacro:`Py_Type()` became :cmacro:`Py_TYPE()`, and
|
|
:cmacro:`Py_Refcnt()` became :cmacro:`Py_REFCNT()`.
|
|
The mixed-case macros are still available
|
|
in Python 2.6 for backward compatibility.
|
|
(:issue:`1629`)
|
|
|
|
* Distutils now places C extensions it builds in a
|
|
different directory when running on a debug version of Python.
|
|
(Contributed by Collin Winter; :issue:`1530959`.)
|
|
|
|
* Several basic data types, such as integers and strings, maintain
|
|
internal free lists of objects that can be re-used. The data
|
|
structures for these free lists now follow a naming convention: the
|
|
variable is always named ``free_list``, the counter is always named
|
|
``numfree``, and a macro :cmacro:`Py<typename>_MAXFREELIST` is
|
|
always defined.
|
|
|
|
* A new Makefile target, "make check", prepares the Python source tree
|
|
for making a patch: it fixes trailing whitespace in all modified
|
|
``.py`` files, checks whether the documentation has been changed,
|
|
and reports whether the :file:`Misc/ACKS` and :file:`Misc/NEWS` files
|
|
have been updated.
|
|
(Contributed by Brett Cannon.)
|
|
|
|
Another new target, "make profile-opt", compiles a Python binary
|
|
using GCC's profile-guided optimization. It compiles Python with
|
|
profiling enabled, runs the test suite to obtain a set of profiling
|
|
results, and then compiles using these results for optimization.
|
|
(Contributed by Gregory P. Smith.)
|
|
|
|
.. ======================================================================
|
|
|
|
Port-Specific Changes: Windows
|
|
-----------------------------------
|
|
|
|
* The support for Windows 95, 98, ME and NT4 has been dropped.
|
|
Python 2.6 requires at least Windows 2000 SP4.
|
|
|
|
* The :mod:`msvcrt` module now supports
|
|
both the normal and wide char variants of the console I/O
|
|
API. The :func:`getwch` function reads a keypress and returns a Unicode
|
|
value, as does the :func:`getwche` function. The :func:`putwch` function
|
|
takes a Unicode character and writes it to the console.
|
|
(Contributed by Christian Heimes.)
|
|
|
|
* :func:`os.path.expandvars` will now expand environment variables
|
|
in the form "%var%", and "~user" will be expanded into the
|
|
user's home directory path. (Contributed by Josiah Carlson.)
|
|
|
|
* The :mod:`socket` module's socket objects now have an
|
|
:meth:`ioctl` method that provides a limited interface to the
|
|
:cfunc:`WSAIoctl` system interface.
|
|
|
|
* The :mod:`_winreg` module now has a function,
|
|
:func:`ExpandEnvironmentStrings`,
|
|
that expands environment variable references such as ``%NAME%``
|
|
in an input string. The handle objects provided by this
|
|
module now support the context protocol, so they can be used
|
|
in :keyword:`with` statements. (Contributed by Christian Heimes.)
|
|
|
|
:mod:`_winreg` also has better support for x64 systems,
|
|
exposing the :func:`DisableReflectionKey`, :func:`EnableReflectionKey`,
|
|
and :func:`QueryReflectionKey` functions, which enable and disable
|
|
registry reflection for 32-bit processes running on 64-bit systems.
|
|
(:issue:`1753245`)
|
|
|
|
* The :mod:`msilib` module's :class:`Record` object
|
|
gained :meth:`GetInteger` and :meth:`GetString` methods that
|
|
return field values as an integer or a string.
|
|
(Contributed by Floris Bruynooghe; :issue:`2125`.)
|
|
|
|
* The new default compiler on Windows is Visual Studio 2008 (VS 9.0). The
|
|
build directories for Visual Studio 2003 (VS7.1) and 2005 (VS8.0)
|
|
were moved into the PC/ directory. The new PCbuild directory supports
|
|
cross compilation for X64, debug builds and Profile Guided Optimization
|
|
(PGO). PGO builds are roughly 10% faster than normal builds.
|
|
(Contributed by Christian Heimes with help from Amaury Forgeot d'Arc and
|
|
Martin von Loewis.)
|
|
|
|
.. ======================================================================
|
|
|
|
Port-Specific Changes: MacOS X
|
|
-----------------------------------
|
|
|
|
* When compiling a framework build of Python, you can now specify the
|
|
framework name to be used by providing the
|
|
:option:`--with-framework-name=` option to the
|
|
:program:`configure` script.
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
.. _section-other:
|
|
|
|
Other Changes and Fixes
|
|
=======================
|
|
|
|
As usual, there were a bunch of other improvements and bugfixes
|
|
scattered throughout the source tree. A search through the change
|
|
logs finds there were XXX patches applied and YYY bugs fixed between
|
|
Python 2.5 and 2.6. Both figures are likely to be underestimates.
|
|
|
|
Some of the more notable changes are:
|
|
|
|
* It's now possible to prevent Python from writing any :file:`.pyc`
|
|
or :file:`.pyo` files by either supplying the :option:`-B` switch
|
|
or setting the :envvar:`PYTHONDONTWRITEBYTECODE` environment variable
|
|
to any non-empty string when running the Python interpreter. These
|
|
are also used to set the :data:`sys.dont_write_bytecode` attribute;
|
|
Python code can change this variable to control whether bytecode
|
|
files are subsequently written.
|
|
(Contributed by Neal Norwitz and Georg Brandl.)
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
Porting to Python 2.6
|
|
=====================
|
|
|
|
This section lists previously described changes and other bugfixes
|
|
that may require changes to your code:
|
|
|
|
* The :meth:`__init__` method of :class:`collections.deque`
|
|
now clears any existing contents of the deque
|
|
before adding elements from the iterable. This change makes the
|
|
behavior match that of ``list.__init__()``.
|
|
|
|
* The :class:`Decimal` constructor now accepts leading and trailing
|
|
whitespace when passed a string. Previously it would raise an
|
|
:exc:`InvalidOperation` exception. On the other hand, the
|
|
:meth:`create_decimal` method of :class:`Context` objects now
|
|
explicitly disallows extra whitespace, raising a
|
|
:exc:`ConversionSyntax` exception.
|
|
|
|
* Due to an implementation accident, if you passed a file path to
|
|
the built-in :func:`__import__` function, it would actually import
|
|
the specified file. This was never intended to work, however, and
|
|
the implementation now explicitly checks for this case and raises
|
|
an :exc:`ImportError`.
|
|
|
|
* C API: the :cfunc:`PyImport_Import` and :cfunc:`PyImport_ImportModule`
|
|
functions now default to absolute imports, not relative imports.
|
|
This will affect C extensions that import other modules.
|
|
|
|
* The :mod:`socket` module exception :exc:`socket.error` now inherits
|
|
from :exc:`IOError`. Previously it wasn't a subclass of
|
|
:exc:`StandardError` but now it is, through :exc:`IOError`.
|
|
(Implemented by Gregory P. Smith; :issue:`1706815`.)
|
|
|
|
* The :mod:`xmlrpclib` module no longer automatically converts
|
|
:class:`datetime.date` and :class:`datetime.time` to the
|
|
:class:`xmlrpclib.DateTime` type; the conversion semantics were
|
|
not necessarily correct for all applications. Code using
|
|
:mod:`xmlrpclib` should convert :class:`date` and :class:`time`
|
|
instances. (:issue:`1330538`)
|
|
|
|
* (3.0-warning mode) The :class:`Exception` class now warns
|
|
when accessed using slicing or index access; having
|
|
:class:`Exception` behave like a tuple is being phased out.
|
|
|
|
* (3.0-warning mode) inequality comparisons between two dictionaries
|
|
or two objects that don't implement comparison methods are reported
|
|
as warnings. ``dict1 == dict2`` still works, but ``dict1 < dict2``
|
|
is being phased out.
|
|
|
|
Comparisons between cells, which are an implementation detail of Python's
|
|
scoping rules, also cause warnings because such comparisons are forbidden
|
|
entirely in 3.0.
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
.. _acks:
|
|
|
|
Acknowledgements
|
|
================
|
|
|
|
The author would like to thank the following people for offering suggestions,
|
|
corrections and assistance with various drafts of this article:
|
|
Georg Brandl, Jim Jewett.
|
|
|