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