PEP 361: Python 2.6/3.0 release schedule
Greetings from Pycon 2008! Neal Norwitz and I have worked out the schedule for Python 2.6 and 3.0, which will be released in lockstep. We will be following a monthly release schedule, with releases to occur on the first Wednesday of the month. We'll move to a 2 week schedule for the release candidates. Executive summary: Python 2.6 and 3.0 finals are planned for September 3, 2008. PEP 361 contains all the gory details; from the PEP: Feb 29 2008: Python 2.6a1 and 3.0a3 are released Apr 02 2008: Python 2.6a2 and 3.0a4 planned May 07 2008: Python 2.6a3 and 3.0a5 planned Jun 04 2008: Python 2.6b1 and 3.0b1 planned Jul 02 2008: Python 2.6b2 and 3.0b2 planned Aug 06 2008: Python 2.6rc1 and 3.0rc1 planned Aug 20 2008: Python 2.6rc2 and 3.0rc2 planned Sep 03 2008: Python 2.6 and 3.0 final http://www.python.org/dev/peps/pep-0361/ This schedule gives everybody plenty of advanced notice, so you should be able to get your code in on time. Please be very careful about not breaking the branches. Neal and I will be cracking the whip of public shame when your commit turns the buildbots red. Embarrassing Pycon pictures of you will be posted if such broken revisions cause us to slip a release, and remember, we know how to use GIMP. On behalf of everyone, here's to an awesome release! -Barry Python 2.6/3.0 release manager
Barry Warsaw wrote:
Greetings from Pycon 2008!
Neal Norwitz and I have worked out the schedule for Python 2.6 and 3.0, which will be released in lockstep. We will be following a monthly release schedule, with releases to occur on the first Wednesday of the month. We'll move to a 2 week schedule for the release candidates.
Hey Barry, Thanks for putting this PEP together. This is really helpful. 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. Best regards, -Travis Oliphant
-----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-----
Barry Warsaw schrieb:
-----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.
I think that [issue1971] ctypes exposing the pep 3118 buffer interface should / could also be backported to 2.6 (once it is merged into py3k). Thomas
-On [20080318 01:52], Barry Warsaw (barry@python.org) wrote:
This schedule gives everybody plenty of advanced notice, so you should be able to get your code in on time.
In particular the memory related fixes over the last weeks, please. :) -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ To love someone deeply gives you strength. Being loved by someone deeply gives you courage...
Possible features for 2.6 New modules in the standard library: - JSON implementation
Have there been any plans made for which one? All of the implementations I'm aware of (cjson, simplejson, jsonlib, demjson, python-json) have serious issues that in my opinion should be fixed before inclusion in the standard library[1]. I am the author of jsonlib, and am willing to write patches for whichever implementation becomes the standard, but it would be very nice to know what to focus on. Apologies if this has been discussed already, but there was no link to a PEP in 361 and a search of python-dev and c.l.p returned no relevant results. [1] * cjson and python-json have almost complete absense of Unicode support. * simplejson is slow and writes incorrect unicode escapes. * demjson is far too forgiving when parsing and accepts all sorts of invalid input. * jsonlib is not PEP 8-compliant and has terrible error handling. * python-json is abandoned, slow, and lacks Unicode support.
I keep forgetting to reply to the list: This is great news. I was getting ready to submit a patch to fix the Unicode handling in simplejson (which I will probably do anyway), but I'm interested in making sure whichever lib will hit the standard library has a correct implementation. Doug On Mar 18, 2008, at 12:17 PM, John Millikin wrote:
Possible features for 2.6 New modules in the standard library: - JSON implementation
Have there been any plans made for which one? All of the implementations I'm aware of (cjson, simplejson, jsonlib, demjson, python-json) have serious issues that in my opinion should be fixed before inclusion in the standard library[1]. I am the author of jsonlib, and am willing to write patches for whichever implementation becomes the standard, but it would be very nice to know what to focus on.
Apologies if this has been discussed already, but there was no link to a PEP in 361 and a search of python-dev and c.l.p returned no relevant results.
[1] * cjson and python-json have almost complete absense of Unicode support. * simplejson is slow and writes incorrect unicode escapes. * demjson is far too forgiving when parsing and accepts all sorts of invalid input. * jsonlib is not PEP 8-compliant and has terrible error handling. * python-json is abandoned, slow, and lacks Unicode support. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/douglas%40openplans.org
!DSPAM:4037,47dfeb7b286095409313003!
participants (6)
-
Barry Warsaw -
Douglas Mayle -
Jeroen Ruigrok van der Werven -
John Millikin -
Thomas Heller -
Travis Oliphant