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:
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
On 1 Mrz., 19:51, Barry Warsaw <ba...@python.org> wrote:
> 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?
Kay Schluehr <kay.schlu...@gmx.net> writes: > On 1 Mrz., 19:51, Barry Warsaw <ba...@python.org> wrote:
> > 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?
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.
-- \ "Dad always thought laughter was the best medicine, which I | `\ guess is why several of us died of tuberculosis." -- Jack | _o__) Handey | Ben Finney
"Kay Schluehr" <kay.schlu...@gmx.net> wrote in message
news:eba3804e-4585-4ec7-85d2-a17513719025@c33g2000hsd.googlegroups.com... | On 1 Mrz., 19:51, Barry Warsaw <ba...@python.org> wrote: | | > 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?
On 2 Mrz., 06:53, Ben Finney <bignose+hates-s...@benfinney.id.au> wrote:
> 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?
On Mar 2, 4:02 am, Kay Schluehr <kay.schlu...@gmx.net> wrote:
> On 2 Mrz., 06:53, Ben Finney <bignose+hates-s...@benfinney.id.au> > wrote:
> > 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?
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.
>On 2 Mrz., 06:53, Ben Finney <bignose+hates-s...@benfinney.id.au> >wrote:
>> 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.
Nevertheless, it IS the answer for many questions in the Python world. That's the advantage of being Benevolent Dictator For Life. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc.
On 2 Mar, 10:02, Kay Schluehr <kay.schlu...@gmx.net> wrote:
> On 2 Mrz., 06:53, Ben Finney <bignose+hates-s...@benfinney.id.au> > wrote:
> > 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?
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.
On Mar 1, 10:53 pm, Kay Schluehr <kay.schlu...@gmx.net> wrote:
> On 1 Mrz., 19:51, Barry Warsaw <ba...@python.org> wrote:
> > 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?
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.
On Mar 1, 10:53 pm, Kay Schluehr <kay.schlu...@gmx.net> wrote:
> On 1 Mrz., 19:51, Barry Warsaw <ba...@python.org> wrote:
> > 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?
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.
news:ir5ns3purngj4kt4ndpptqnqm5pj628qbj@4ax.com... | Kay Schluehr <kay.schlu...@gmx.net> wrote: | >"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.
|
