[python-advocacy] Fwd: [media inquiry] About your views on the Python 2.6 release
goodger at python.org
Mon Oct 6 20:13:41 CEST 2008
FYI & for future reference.
The story was published on Friday (2008-10-03):
---------- Forwarded message ----------
From: David Goodger <goodger at python.org>
Date: Fri, Oct 3, 2008 at 12:03
Subject: Re: [media inquiry] About your views on the Python 2.6 release
To: Sean Kerner <skerner at jupitermedia.com>
On Thu, Oct 2, 2008 at 15:57, Sean Kerner <skerner at jupitermedia.com> wrote:
> Q: What do you see as the most noteworthy new items in Python 2.6?
> How will they help python developers today?
Python 2.6 is an incremental release, with many new features and lots of
bug-fixes, but it remains backwards-compatible with 2.X code. Some
* The "with" statement (introduced as an optional feature in Python
2.5) makes it easy to implement features that require guaranteed
execution of setup and finalization code, like database transactions
and acquiring/releasing locks.
* Support for the str.format() text formatting method, a more powerful
alternative to the "%" operator, has been added.
* The new "multiprocessing" package enables the efficient use of
multiple CPU cores within a machine and even multiple machines.
* Support for abstract base classes have been added with the new "abc"
See Andrew Kuchling's "What's New in Python 2.6" document for all
the details: http://docs.python.org/whatsnew/2.6.html
> Q: I know a key part of python 2.6 is python 3 compatibility - Why
> should developers care about Python 3? How will it make their
> lives/code better?
Python 2.6 isn't about Python 3 compatibility, it's about Python 2.X
compatibility. We are not expecting (or encouraging!) developers to
migrate to Python 3 immediately, and the Python 2.X line will continue
to be supported and improved for years to come. Python 2.6 is an
upgrade intended for most developers of production systems. Python
3.0 is for those who like to live on the bleeding edge.
Python 2.6 does pave the way for future migration to Python 3.0, which
is a major redesign of the language. Here "major" means "backwards
incompatible", but superficially surprisingly little has changed; it's
Python 3 is about cleaning up the Python language, revisiting earlier
design decisions that are now considered flaws, and fixing them.
Python 3 improves the foundations of Python going forward.
Specifically, there is an execution mode that warns about
incompatibilities with Python 3, the "-3" command-line option. Also,
Python 2.6 includes a tool called "2to3" which converts Python 2.6
code to be compatible with Python 3.0.
> Q: How does Python 3 rc1 compare/contrast in terms of features and
> functions with Python 2.6?
First, a clarification: "rc1" means "release candidate 1". It's a
step on the way to the final release of Python 3.0. Recently, an
issue arose which will delay the final release of Python 3.0, and the
next step will probably be another beta release. I expect the final
release of Python 3.0 within the next month or so, but the actual date
will be determined by the state of the codebase. Python 3.0 will ship
when it's ready, and not before.
Python 2.6 gains several of the features of Python 3.0, but not all.
Whenever possible, Python 2.6 incorporates new features and syntax
from 3.0 while remaining compatible with existing code. Some of these
new features and syntax are accessible through "from __future__ import
..." statements. This allows developers to use features that would
otherwise introduce incompatibilities, on a module-by-module basis.
> Q: What are the challenges that python developers and applications
> will have in migrating from Python 2.x up to Python 3?
I think the biggest challenge will be exercising restraint.
Developers who want to migrate their applications should go slowly.
It will take some time, probably years, before Python 3.X takes over
from Python 2.X. Most applications rely on third-party libraries,
which have to migrate first. Some applications need never migrate to
Python 3. Python 2.X isn't going away.
Migrating a codebase from Python 2.X to 3.X one-way, without going
back, should be easy. The 2to3 tool will do most of the work, but a
good suite of unit tests with full code coverage is essential, to this
or any large change.
Developers who maintain both 2.X and 3.X versions of their codebases
will have to exercise the most caution. The recommended procedure is to always
use the automated tools to convert from 2.6 to 3.0, and only edit the
2.6 code. First port the project to Python 2.6, test and edit with
the "-3" warnings mode until no warnings remain, and use the 2to3 tool
to convert to Python 3.0 syntax. The Python 3 version of the codebase
should be tested, and if any problems are found, corrections should be
made to the **Python 2.6** version only, and then repeat the process.
As Guido van Rossum wrote: "It is **strongly** recommended not to start
editing the 3.0 source code until you are ready to reduce 2.6 support
to pure maintenance."
> Q: Will there be a 2.7 release tied to a Python 3 rc 2 release
Yes, there will be a Python 2.7 release, probably tied to a the
release of Python 3.1.
> Q: As part of this release, Python development has moved to a new
> bug tracking system (Roundup) from what you can tell so far – will
> Roundup provide for improved bug quashing efforts?
Yes. Roundup streamlines issue tracking immensely, so there is less
time and effort spent on issue administration and more on fixing bugs
and implementing new features.
> Thanks in advance for your time and prompt reply.
Please send me a link to the article once it's published.
David Goodger <http://python.net/~goodger>
More information about the Advocacy