[Python-Dev] [Python-3000] PEP 361: Python 2.6/3.0 release schedule

Tue Mar 18 15:47:51 CET 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote:
>> Hey Barry,
>> Thanks for putting this PEP together. This is really helpful.

Hi Travis... thanks!
> I didn't see discussion of PEP 3118 and it's features back-ported to
> Python 2.6. I've already back-ported the new buffer API as an 
> addition
> to the old buffer protocol.
>> In addition, I've planned to back-port the improvements to the struct
> module and the addition of the memoryview object (both in PEP 3118).
>> If you have questions, we can talk tomorrow.

Let's do that. Neal has put together a list of things that he thinks 
needs to be backported. We should formalize that list (as best we can 
given we're still in alpha), and add it to the PEP. I think we should 
also make sure we have open issues in the tracker for each backporting 
task.
Neal and I talked about this yesterday too and came up with some 
general guidelines. The view we have is that through conservative use 
of future imports and backports, we want to start closing the gap 
between 2.6 and 3.0. It'll still be fairly wide though, so we'll use 
2.7/3.1 to close it even further by doing things like backporting more 
stuff, de-futurizing features in 2.6, etc. It may be that we should 
take a very conservative approach to new features in the next few 
major release (in both families), concentrating instead on stabilizing 
what we've got and helping make the transition less and less painful. 
So you could imagine that 2.8/3.2 would close the gap far enough that 
it wouldn't be much more work to move from 2.8 to 3.2 than it would be 
to move from 2.5 to 2.6.
Some other thoughts: we might want to shorten our post 2.6/3.0 release 
cycles, say to 1 year or less so that we can help speed this 
transition. If we try hard to keep new features to a minimum, this 
might be possible, but we also have to avoid churn. Quite a few 
people expressed to me that it might be 5 years before they switch 
fully to 3.0. That seems fine to me, given that some big Python shops 
are still on 2.2 or <gasp> 1.5 and 1.6. So 3 years from 2.6/3.0 to 
2.8/3.2 doesn't seem to wildly outrageous to me.
Given this longer view of the transition, we can be more conservative 
about what we backport to 2.6. A general principle would be anything 
that is brand new syntax in 3.0 can be backported, because there won't 
be any existing code in 2.6 that could break. Anything that can be 
enabled through a future-import might be a candidate, but you have to 
be careful about tricky semantic differences. For example, changing 
the meaning of dict.keys() via a future-import is not a good idea.
One thing I would like to see is "from __future__ import 
unicode_strings" or some such. The only thing this would do is allow 
you to write unicode string literals in Python 2.6 without the u'' 
prefix. That's a fairly localized change (affecting just the file the 
literals appear in), but it would go a long way toward closing that gap.
One question that came up was whether we have enough bitfields to 
handle all the future statements we might have, and whether you even 
want to see Python 2.6 code sprinkled with lots of future statements. 
Does it make sense to have a "from __future__ import python3" 
umbrella? Will we really have that many future statements?
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR9/WGHEjvBPtnXfVAQLP1AP+OpSuXHDgE1uxifKA6FEKxS1Zms1Pe0ww
OimG2kw3afzL5+o1mdrRBUDy/rETpNhlxBTgx+fgI7VJc+Vs+uBi0sQwemCqOZ1I
9qlBFCo8YrmXlCZTdL9E0nEpiBSuanLKJcdNP8VU3QjbOX0EKqNTfK1asSckxvgT
H1o5wGqnX5M=
=wiJQ
-----END PGP SIGNATURE-----