[Python-Dev] [Python-3000] PEP 361: Python 2.6/3.0 release schedule
barry at python.org
Tue Mar 18 15:47:51 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
-----END PGP SIGNATURE-----
More information about the Python-Dev