RELEASED Python 2.6a1 and 3.0a3

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On behalf of the Python development team and the Python community, I'm
happy to announce the first alpha release of Python 2.6, and the third
alpha release of Python 3.0.

Python 2.6 is not only the next advancement in the Python 2 series, it
is also a transitionary release, helping developers begin to prepare
their code for Python 3.0. As such, many features are being
backported from Python 3.0 to 2.6. It makes sense to release both
versions in at the same time, the precedence for this having been set
with the Python 1.6 and 2.0 releases.

During the alpha testing cycle we will be releasing both versions in
lockstep, on a monthly release cycle. The releases will happen on the
last Friday of every month. If this schedule works well, we will
continue releasing in lockstep during the beta program. See PEP 361
for schedule details:

http://www.python.org/dev/peps/pep-0361/

Please note that these are alpha releases, and as such are not
suitable for production environments. We continue to strive for a
high degree of quality, but there are still some known problems and
the feature sets have not been finalized. These alphas are being
released to solicit feedback and hopefully discover bugs, as well as
allowing you to determine how changes in 2.6 and 3.0 might impact
you. If you find things broken or incorrect, please submit a bug
report at

http://bugs.python.org

For more information and downloadable distributions, see the Python
2.6 web
site:

http://www.python.org/download/releases/2.6/

and the Python 3.0 web site:

http://www.python.org/download/releases/3.0/

We are planning a number of additional alpha releases, with the final
release schedule still to be determined.

Enjoy,
- -Barry

Barry Warsaw
(e-mail address removed)
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8mlu3EjvBPtnXfVAQKePAQAgx6w9wztfJaSWkbKrbwur2U6t6o5aIY5
pyMa00CZWY06p8099BztcSjgp5rKrd6/9V7cJ0NP7NLZ+tz20uRfyI8uqoIYBIWC
ibJay6SSnzgOQM3PRIJV/K/m0dVPPPVD1LDnoEvuu+cKUpV434yHdgWkMPswsxUd
fLydrXABlOM=
=l6aj
-----END PGP SIGNATURE-----

 

[Kay Schluehr]

Python 2.6 is not only the next advancement in the Python 2 series, it
is also a transitionary release, helping developers begin to prepare
their code for Python 3.0.

Isn't this a silly idea? People have to migrate from 2.5 or lower
releases to Python 2.6 first just to migrate to Python 3.0? What are
the inherent / technical reasons that prevent migration directly from
2.5 to 3.0?

 

[Ben Finney]

Isn't this a silly idea? People have to migrate from 2.5 or lower
releases to Python 2.6 first just to migrate to Python 3.0? What are
the inherent / technical reasons that prevent migration directly from
2.5 to 3.0?

One of the stated goals of the migration is that the '2to3' program
will only migrate Python 2.6 code -> Python 3.0 code. So, the
smoothest migration path will be:

* get your program working with Python 2.6; then

* use '2to3' to automatically translate that program to work with
Python 3.0; then

* stop using Python 2.x for that program, only use Python 3.x.

Another reason is that good features from Python 3.0 will likely be
backported (if possible) to Python 2.6.x, but not to any earlier
version.

 

[Terry Reedy]

|
| > Python 2.6 is not only the next advancement in the Python 2 series, it
| > is also a transitionary release, helping developers begin to prepare
| > their code for Python 3.0.
|
| Isn't this a silly idea? People have to migrate from 2.5 or lower
| releases to Python 2.6 first just to migrate to Python 3.0?

You are quite free to update any code you want. Barry just said that 2.6
will help make the process easier. (At least it should for people who
prefer incremental changes to doing it all at once.) In any case, 2.5 and
earlier code that does not depend on bugs later fixed should usually run
unchanged in 2.6

| What are
| the inherent / technical reasons that prevent migration directly from
| 2.5 to 3.0?

None.

tjr

 

[Kay Schluehr]

One of the stated goals of the migration is that the '2to3' program
will only migrate Python 2.6 code -> Python 3.0 code.

Yes, I know. Why?

"The master said so" isn't an entirely satisfying answer. What are the
*technical reasons* that make it hard to apply '2to3' directly on
Python 2.4 or Python 2.5?

 

[Carl Banks]

Yes, I know. Why?

"The master said so" isn't an entirely satisfying answer. What are the
*technical reasons* that make it hard to apply '2to3' directly on
Python 2.4 or Python 2.5?

Well, even if you wanted to apply 2to3 to Python 2.5, you'd (probably)
have to modify your code to make it 2to3-compatible. So if you're
going to do that, you might as well upgrade to 2.6 to take advantage
of new warnings and new idioms that are more conducive automatic
translation.

2to3 is not a general tool to convert any given source code from 2.6
to 3.0. It's designed to make it possible to write code that works in
Python 2.6 and Python 3.0, but to do that you have to use a
"transitional Python" dialect that's a subset of 2.6. (It would be
quite to attempt a general code translator, of course.)

Anyway, I think there are a few cases in Python 2.5 where there's no
easy way to write something that 2to3 can handle, and some
specifically transitional features were added to 2.6 to remedy this.
I don't recall specifics, though. It may be for the cases where
things that previously returned lists now return iterators.

Finally, 2.6 will have the benefit of being cross-checked with 3.0 to
ensure that 2to3 does what it's supposed to when used as intended.
All bets are off if you attempt it with 2.5.

In the end, the real *technical* reason might have been the developers
thought it wasn't worth the effort to backport it to 2.5. The above
problems were probably solvable with enough effort, but would that
have been a wise use of resources?

One parenthetical I will add: 2to3 always seemed to me to be more of a
way to enfore constraint on the design of Python 3.0. If a proposed
feature couldn't be automatically ported to 3.0, then it was a big
strike against the proposal. That it could end up being a useful
transitional tool is nice, but it never seemed to be its primary
purpose.


Carl Banks

 

[Ben Finney]

Yes, I know. Why?

"The master said so" isn't an entirely satisfying answer.

The people putting in the work to write '2to3' said so.

 

[Tim Roberts]

Yes, I know. Why?

"The master said so" isn't an entirely satisfying answer.

Nevertheless, it IS the answer for many questions in the Python world.
That's the advantage of being Benevolent Dictator For Life.

 

[Paul Boddie]

Yes, I know. Why?

"The master said so" isn't an entirely satisfying answer. What are the
*technical reasons* that make it hard to apply '2to3' directly on
Python 2.4 or Python 2.5?

I imagine that in Python 2.6 there are some semantic changes
(conveniences, really), plus some expansion of the language syntax to
overlap with Python 3, both of which let the 2to3 tool work as
intended. Obviously 2to3 doesn't do too much complicated stuff, and I
imagine (or have deduced from what I've heard) that you have to write
code that is "obvious" to the tool so that it can translate it
correctly. Perhaps 2.5 and earlier don't permit such obvious code to
be written.

Paul

 

[dave_mikesell]

Isn't this a silly idea? People have to migrate from 2.5 or lower
releases to Python 2.6 first just to migrate to Python 3.0? What are
the inherent / technical reasons that prevent migration directly from
2.5 to 3.0?

Not only that, you have to wait for your library providers to migrate
first (PyOpenGL, PyGame, PIL, etc for me). Hopefully this is the
last quantum shift for a while.

 

[dave_mikesell]

Isn't this a silly idea? People have to migrate from 2.5 or lower
releases to Python 2.6 first just to migrate to Python 3.0? What are
the inherent / technical reasons that prevent migration directly from
2.5 to 3.0?

Not only that, you have to wait for your library providers to migrate
first (PyOpenGL, PyGame, PIL, etc for me). Hopefully this is the
last quantum shift for a while.

 

[Terry Reedy]

| >"The master said so" isn't an entirely satisfying answer.
|
| Nevertheless, it IS the answer for many questions in the Python world.

But not for the questions about 2to3

Current 2to3 is written in Py2.5 and will require the 2.5 interpreter until
2.6 is sufficiently stable to run it. Whether it will later use 2.6
features or not I do not know.

I believe that pre-2.6 code will be directly upgradable if
A. it does not depend on bugs that are fixed by 2.6,
so that it is also 2.6 code;
B. one is willing to do the upgrade more or less 'all at once',
(while the code is frozen);
C. one is willing to do *one* of the following:
C1. keep the 2.x code frozen, or
C2. redo the upgrade more or less 'from scratch' after base code edits,
or
C3. maintain the 2.x code and 3.0 code in parallel

These are facts of programming life, not BDFL edicts. But many will prefer
an incremental approach.

Py 2.6 will ease this by 1) optionally issuing upgrade warnings, and 2)
incorporating many new 3.0 features that do not conflict with 2.x features.

tjr