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

[Barry Warsaw]

-----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-----