[RELEASED] Python 2.7 alpha 2
On behalf of the Python development team, I'm gleeful to announce the second alpha release of Python 2.7. Python 2.7 is scheduled to be the last major version in the 2.x series. It includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python distribution. To download Python 2.7 visit: http://www.python.org/download/releases/2.7/ Please note that this is a development release, intended as a preview of new features for the community, and is thus not suitable for production use. The 2.7 documentation can be found at: http://docs.python.org/2.7 Please consider trying Python 2.7 with your code and reporting any bugs you may notice to: http://bugs.python.org Have fun! -- Benjamin Peterson 2.7 Release Manager benjamin at python.org (on behalf of the entire python-dev team and 2.7's contributors)
On Sat, Jan 9, 2010 at 12:29 PM, Benjamin Peterson <benjamin@python.org>wrote:
On behalf of the Python development team, I'm gleeful to announce the second alpha release of Python 2.7.
Well yay. Django's test suite (1242 tests) runs with just one failure on the 2.7 alpha 2 level, and that looks to be likely due to the improved string/float rounding so not really a problem, just a difference. That's down from 104 failures and 40 errors with 2.7 alpha 1. Note on the website page http://www.python.org/download/releases/2.7/ the "Change log for this release" link is still pointing to the alpha 1 changelog. Thanks, Karen
2010/1/9 Karen Tracey <kmtracey@gmail.com>:
On Sat, Jan 9, 2010 at 12:29 PM, Benjamin Peterson <benjamin@python.org> wrote:
On behalf of the Python development team, I'm gleeful to announce the second alpha release of Python 2.7.
Well yay. Django's test suite (1242 tests) runs with just one failure on the 2.7 alpha 2 level, and that looks to be likely due to the improved string/float rounding so not really a problem, just a difference. That's down from 104 failures and 40 errors with 2.7 alpha 1.
Excellent!
Note on the website page http://www.python.org/download/releases/2.7/ the "Change log for this release" link is still pointing to the alpha 1 changelog.
Thanks. I'll fix that.
-- Regards, Benjamin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karen Tracey wrote:
On Sat, Jan 9, 2010 at 12:29 PM, Benjamin Peterson <benjamin@python.org>wrote:
On behalf of the Python development team, I'm gleeful to announce the second alpha release of Python 2.7.
Well yay. Django's test suite (1242 tests) runs with just one failure on the 2.7 alpha 2 level, and that looks to be likely due to the improved string/float rounding so not really a problem, just a difference. That's down from 104 failures and 40 errors with 2.7 alpha 1.
Note on the website page http://www.python.org/download/releases/2.7/ the "Change log for this release" link is still pointing to the alpha 1 changelog.
Just to add another "success" data point: Zope2's trunk, as well as the 2.12 release, passes all tests (2535 on the trunk) and brings up the appserver just fine under 2.7a2. There is an obnoxious deprecation warning out of the distutils: DeprecationWarning: 'compiler' specifies the compiler type in build_ext. If you want to get the compiler object itself, use 'compiler_obj' which is likely a simple one-line fix, if I only knew what the hell it was whining about. ;) The warning is extra obnoxious because it doesn't tell me what in *my* code triggers the warning (it (needs a 'stacklevel' argument). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktNNqQACgkQ+gerLs4ltQ7d5gCcCGKVjyOlxnrAln0UnRibS7kd lNIAoIs1RlSGMtJWaY11BqptfDmQvR87 =mIOO -----END PGP SIGNATURE-----
Tres Seaver wrote:
There is an obnoxious deprecation warning out of the distutils:
DeprecationWarning: 'compiler' specifies the compiler type in build_ext. If you want to get the compiler object itself, use 'compiler_obj'
which is likely a simple one-line fix, if I only knew what the hell it was whining about. ;) The warning is extra obnoxious because it doesn't tell me what in *my* code triggers the warning (it (needs a 'stacklevel' argument).
Could you kick a tracker issues in Tarek's direction for that one? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nick Coghlan wrote:
Tres Seaver wrote:
There is an obnoxious deprecation warning out of the distutils:
DeprecationWarning: 'compiler' specifies the compiler type in build_ext. If you want to get the compiler object itself, use 'compiler_obj'
which is likely a simple one-line fix, if I only knew what the hell it was whining about. ;) The warning is extra obnoxious because it doesn't tell me what in *my* code triggers the warning (it (needs a 'stacklevel' argument).
Could you kick a tracker issues in Tarek's direction for that one?
Done: http://bugs.python.org/issue7694 Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktN+bMACgkQ+gerLs4ltQ6s4gCdENhtVQWzoH449BCDz8SNx/4s DEoAn19LMcMs3b6ctdNF8K2hYd6d+BSZ =TWit -----END PGP SIGNATURE-----
Benjamin Peterson <benjamin@python.org> wrote:
On behalf of the Python development team, I'm gleeful to announce the second alpha release of Python 2.7.
Thanks to everyone who contributed.
Python 2.7 is scheduled to be the last major version in the 2.x series.
Has this really been decided already? Maybe I missed it. In my opinion, it does Python's reputation harm to make such a statement. Conservative users (probably the vast majority of Python users) don't like to hear that software they are considering using is nearing the end of its life. What does it gain us to announce that the 2.x branch is dead aside from bugfixes? I propose that the 2.x branch be treated like 2.x.y branches: as long as there is sufficient volunteer labour, it should continue to live. In order to avoid wasted development effort, it would be prudent to announce that unless a 2.8 release manager steps up, whatever is committed to the 2.x branch after the 2.7 release may never get released. Said another way, it's okay for the Python developers to decide to abandon 2.x and put their efforts into 3.x. It's not okay for them to prevent others from continuing to work on 2.x or to somehow make 2.x look worse so 3.x looks better. Python 3 needs to stand on its own terms and I'm confident it can. Best regards, Neil
On Sun, Jan 10, 2010 at 11:30, Neil Schemenauer <nas@arctrix.com> wrote:
Benjamin Peterson <benjamin@python.org> wrote:
On behalf of the Python development team, I'm gleeful to announce the second alpha release of Python 2.7.
Thanks to everyone who contributed.
Python 2.7 is scheduled to be the last major version in the 2.x series.
Has this really been decided already? Maybe I missed it.
More or less. It was first discussed at the language summit last year and has come up here a couple of times. If needed we can make it official in terms of lifetime of 2.7, etc. at the language summit this year.
In my opinion, it does Python's reputation harm to make such a statement. Conservative users (probably the vast majority of Python users) don't like to hear that software they are considering using is nearing the end of its life. What does it gain us to announce that the 2.x branch is dead aside from bugfixes?
I propose that the 2.x branch be treated like 2.x.y branches: as long as there is sufficient volunteer labour, it should continue to live. In order to avoid wasted development effort, it would be prudent to announce that unless a 2.8 release manager steps up, whatever is committed to the 2.x branch after the 2.7 release may never get released.
Said another way, it's okay for the Python developers to decide to abandon 2.x and put their efforts into 3.x. It's not okay for them to prevent others from continuing to work on 2.x or to somehow make 2.x look worse so 3.x looks better. Python 3 needs to stand on its own terms and I'm confident it can.
I don't think ending the 2.x series at 2.7 makes it look bad compared to 3.2; it's simply the end of a development line like any other software project. I suspect 2.7 will have a protracted bugfix window because so much code runs on 2.x exclusively at the moment. And if core developers want to continue to backport fixes past two years from release they can (or however long we decide to officially support 2.7). No one is saying people still can't work on the code, just that python-dev as an entity is not going to focus its effort on the 2.x series anymore and people should not rely upon us to continue to focus new development efforts in that series. If there are core developers who want to continue to do bugfix releases then that's fine and I am happy to flag patches as needing backports and let other's do the work after the standard two year maintenance cycle, but I know I do not want to be held accountable as a core developer to keep the 2.x going indefinitely. Maintaining four branches is enough of a reason in my book to not keep the 2.x series going. If there really is an outcry on this we can re-visit the issue, but as of right now we need to move forward at some point and 2.7 seems like that good point. -Brett
On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote:
I don't think ending the 2.x series at 2.7 makes it look bad compared to 3.2; it's simply the end of a development line like any other software project. I suspect 2.7 will have a protracted bugfix window because so much code runs on 2.x exclusively at the moment.
I would guess over 99% of all Python code written doesn't run on Python 3. Given that, I think it is premature to close the door on new major versions of Python 2.x. Also, we as a project should be careful not to present the image that Python 2.x will not be supported in the future.
If there really is an outcry on this we can re-visit the issue, but as of right now we need to move forward at some point and 2.7 seems like that good point.
I think that's bad PR. If I had a successful product, I would not announce its end of life just to see how many customers scream and then decide if I should devote more resources to continue maintaining it. IMHO, the release notes should say something like: After the Python 2.7 release, the focus of Python development will be on Python 3. There will continue to be maintainance releases of Python 2.x. trying-to-head-off-the-python-is-dying-meme-ly y'rs Neil
On 1/10/2010 8:44 PM, Neil Schemenauer wrote:
On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote:
I don't think ending the 2.x series at 2.7 makes it look bad compared to 3.2; it's simply the end of a development line like any other software project. I suspect 2.7 will have a protracted bugfix window because so much code runs on 2.x exclusively at the moment.
I would guess over 99% of all Python code written doesn't run on Python 3.
If the removal of old features had been done in the 2.x series, as once planned (Guido originally proposed removing the old meaning of int / int in 2.5) the same more or less would be true of 2.7. It is past time for other old and now duplicated features to be removed also. Given that, I think it is premature to close the door on
new major versions of Python 2.x. Also, we as a project should be careful not to present the image that Python 2.x will not be supported in the future.
If there really is an outcry on this we can re-visit the issue, but as of right now we need to move forward at some point and 2.7 seems like that good point.
I think that's bad PR. If I had a successful product, I would not announce its end of life just to see how many customers scream and then decide if I should devote more resources to continue maintaining it.
Python is not being ended, but upgraded (with bloating duplications removed). Think of 3.1 as 2.8 with a new name. tjr
On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer <nas@arctrix.com> wrote:
On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote:
I don't think ending the 2.x series at 2.7 makes it look bad compared to 3.2; it's simply the end of a development line like any other software project. I suspect 2.7 will have a protracted bugfix window because so much code runs on 2.x exclusively at the moment.
I would guess over 99% of all Python code written doesn't run on Python 3. Given that, I think it is premature to close the door on new major versions of Python 2.x.
Well yeah; Python 3.0 is just over a year old with 3.1 -- the first robust 3.x release - is about six months old. From the beginning uptake was expected to take years, not months, so saying that 3.x is not popular enough seems premature.
Also, we as a project should be careful not to present the image that Python 2.x will not be supported in the future.
No one has said bugfixes will cease.
If there really is an outcry on this we can re-visit the issue, but as of right now we need to move forward at some point and 2.7 seems like that good point.
I think that's bad PR. If I had a successful product, I would not announce its end of life just to see how many customers scream and then decide if I should devote more resources to continue maintaining it.
I never said that I wanted to make this announcement specifically to provoke outcries. I said if there happened to be outcries we could possibly visit the issue again. Basically I was being considerate and trying to leave the door open to discuss things in the future even though I don't see the situation changing.
IMHO, the release notes should say something like:
After the Python 2.7 release, the focus of Python development will be on Python 3. There will continue to be maintainance releases of Python 2.x.
No because that suggests new features will be coming to 2.x which is not going to happen. If you want to say there will be continual bugfix releases for 2.7 as is par the course for Python and that the number of bugfix releases might be more than normal then I am okay with that.
trying-to-head-off-the-python-is-dying-meme-ly y'rs Neil
That came and went already a couple months ago when we discussed stopping at 2.6 instead of 2.7 (see the various threads at http://mail.python.org/pipermail/python-dev/2009-November/thread.html). -Brett
On Sun, Jan 10, 2010 at 07:46:04PM -0800, Brett Cannon wrote:
On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer <nas@arctrix.com> wrote:
After the Python 2.7 release, the focus of Python development will be on Python 3. There will continue to be maintainance releases of Python 2.x.
No because that suggests new features will be coming to 2.x which is not going to happen. If you want to say there will be continual bugfix releases for 2.7 as is par the course for Python and that the number of bugfix releases might be more than normal then I am okay with that.
Are you are saying that if someone steps up to merge the Unladen Swallow features into a 2.8 release and someone also steps up to cut the release that they will be prevented from doing so? Also, are you presuming to channel the BDFL or was this dicussed somewhere other than python-dev? Maybe I'm overreacting but I get the feeling that the larger and less active segment of the Python develpment team hasn't been involved in these decisions. Best regards, Neil
On Sun, Jan 10, 2010 at 20:05, Neil Schemenauer <nas@arctrix.com> wrote:
On Sun, Jan 10, 2010 at 07:46:04PM -0800, Brett Cannon wrote:
On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer <nas@arctrix.com> wrote:
After the Python 2.7 release, the focus of Python development will be on Python 3. There will continue to be maintainance releases of Python 2.x.
No because that suggests new features will be coming to 2.x which is not going to happen. If you want to say there will be continual bugfix releases for 2.7 as is par the course for Python and that the number of bugfix releases might be more than normal then I am okay with that.
Are you are saying that if someone steps up to merge the Unladen Swallow features into a 2.8 release and someone also steps up to cut the release that they will be prevented from doing so?
I honestly don't know, but it's a possibility just like any other new feature request. If people start taking the carrots we have added to 3.x and backporting them to keep the 2.x series alive you are essentially making the 3.x DOA by negating its benefits which I personally don't agree with.
Also, are you presuming to channel the BDFL or was this dicussed somewhere other than python-dev?
This was discussed; see the November 2009 threads. Guido actually suggested ending the 2.x branch at 2.6 until people spoke up about the amount of stuff already backported to 2.7 from 3.x because it was being assumed to be the end of the series to warrant keeping it to help transition to 2.7.
Maybe I'm overreacting but I get the feeling that the larger and less active segment of the Python develpment team hasn't been involved in these decisions.
This all came up in November from the 3rd through the 6th (four days) over a ton of email traffic. This was not a snap decision but a heated discussion where even Guido participated that culminated with the decision to stop at 2.7 for the 2.x series; this was not a smoked-filled room decision. I'm sorry if people missed it when they weren't looking, but python-dev is supposed to be the place to watch for this kind of stuff. I don't know how else to bring this stuff to people's attention short of also on python-committers, but developers are basically expected to be on both lists so I don't see where anyone did anything wrong in terms of informing developers. -Brett
On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
If people start taking the carrots we have added to 3.x and backporting them to keep the 2.x series alive you are essentially making the 3.x DOA by negating its benefits which I personally don't agree with.
I think we have got to the heart of our disagreement. Assume that some superhuman takes all the backwards compatible goodies from 3.x and merges them into 2.x. If that really would kill off Python 3 then I would proclaim it a project that deserved to die. Why should the backwards incompatible changes be endured if they cannot justify their existance by the benefit they provide? I guess I have more confidence in Python 3 than you do. I don't see why Python 2.x needs to be artificially limited so that Python 3 can benefit. Regards, Neil
On Sun, Jan 10, 2010 at 21:27, Neil Schemenauer <nas@arctrix.com> wrote:
On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
If people start taking the carrots we have added to 3.x and backporting them to keep the 2.x series alive you are essentially making the 3.x DOA by negating its benefits which I personally don't agree with.
I think we have got to the heart of our disagreement. Assume that some superhuman takes all the backwards compatible goodies from 3.x and merges them into 2.x. If that really would kill off Python 3 then I would proclaim it a project that deserved to die. Why should the backwards incompatible changes be endured if they cannot justify their existance by the benefit they provide?
When I said "carrots" I meant everything that makes Python 3 the best version of Python, including the backward-incompatible changes. I guess I have more confidence in Python 3 than you do. I don't see
why Python 2.x needs to be artificially limited so that Python 3 can benefit.
I don't view it as artificial but simply a focusing of the development team on what has been determined as the future of Python by Guido and letting go of the past. IMO keeping Python 2.x around past 2.7 is the equivalent of python-dev saying "Python 3 is the future, but we are keeping the old Python 2.x around because we don't have *that* much faith in the future we have laid out". That's poison to Python 3 by showing a lack of confidence in the direction that the BDFL and python-dev as a group has chosen. Now I could be wrong and there could actually be a large number of active contributors who want to keep the 2.x series going, but based on the discussion that occurred the last time this came up I believe the guys who are keeping Python running are ready to move on. -Brett
Brett Cannon wrote:
IMO keeping Python 2.x around past 2.7 is the equivalent of python-dev saying "Python 3 is the future, but we are keeping the old Python 2.x around because we don't have *that* much faith in the future we have laid out". That's poison to Python 3 by showing a lack of confidence in the direction that the BDFL and python-dev as a group has chosen. Now I could be wrong and there could actually be a large number of active contributors who want to keep the 2.x series going, but based on the discussion that occurred the last time this came up I believe the guys who are keeping Python running are ready to move on.
I think this is mostly just a branding issue. Once the folks who have historically kept Python 2 running really *do* move on, there will be other folks who will step up and become maintainers out of necessity: those stuck on old platforms, permanent stragglers, people who for whatever reason actually like Python 2 better, etc. It's just going to happen, there's really nothing anybody can do about it. I don't think there's anything wrong with this. If such a group of folks wants to get together and create another Python 2.X release, there's nothing stopping them from doing so except the above branding declaration. I'd personally not close the door on allowing these folks to call such an effort "Python 2". - C
On Mon, Jan 11, 2010 at 06:27, Neil Schemenauer <nas@arctrix.com> wrote:
I think we have got to the heart of our disagreement. Assume that some superhuman takes all the backwards compatible goodies from 3.x and merges them into 2.x.
The superhumans of core developers pretty much already have. That's pretty much 2.7 you are talking about. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
I guess I have more confidence in Python 3 than you do. I don't see why Python 2.x needs to be artificially limited so that Python 3 can benefit.
Because it takes too much time. Too much of my time, but apparently also too much of other people's time. Of course, the less active fraction of Python contributors may not notice, since they just chose to not contribute (which, of course, is fine). However, asking me to work twice as much as I want to on the project to keep two branches alive is just unfair. This has nothing to do with pushing 3.x, but all with managing available manpower and still providing quality software. Regards, Martin
This is what it says now: "Python 2.7 is scheduled to be the last major version in the 2.x series before it moves into 5 years of bugfix-only mode. " And during this discussion it has been noted that others than the core python team might pick up Python 2 and make releases. So maybe we can and this discussion by changing that line in future releases to be: "Python 2.7 is scheduled to be the last major version in the 2.x series released by the Python Software Foundation before it moves into 5 years of bugfix-only mode. " That doesn't exclude *others* making a Python 2.8 that could include all sorts of crazy features. :) This is mainly just to get the pointless discussion over with. The current Python core team don't want to make a 2.8, so that will not happen. Someone else might, but as Chris points out, they won't step up until they have to, which is probably at least two years from now. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
"Python 2.7 is scheduled to be the last major version in the 2.x series released by the Python Software Foundation before it moves into 5 years of bugfix-only mode. "
That doesn't exclude *others* making a Python 2.8 that could include all sorts of crazy features. :)
This is mainly just to get the pointless discussion over with.
I know you are just looking for a compromise, but this shouldn't be it: the PSF has deliberately stayed out of the actual Python engineering, so the release that Benjamin makes is not done by the PSF (but by Benjamin and his contributors :-). I like the wording as it is (although I find the promise of five years of bug fix releases a bit too strong). Regards, Martin
On Mon, Jan 11, 2010 at 10:06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I know you are just looking for a compromise, but this shouldn't be it: the PSF has deliberately stayed out of the actual Python engineering, so the release that Benjamin makes is not done by the PSF (but by Benjamin and his contributors :-).
Hm. Yeah. That's right of course. I started with saying "official", but then I thought "official according to who?". :) So I changed it to mentioning PSF, but that doesn't work either. I guess the current writing as as good as it gets, unless we change "scheduled" to "expected" or something. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
On Mon, Jan 11, 2010 at 10:06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I know you are just looking for a compromise, but this shouldn't be it: the PSF has deliberately stayed out of the actual Python engineering, so the release that Benjamin makes is not done by the PSF (but by Benjamin and his contributors :-).
Hm. Yeah. That's right of course. I started with saying "official", but then I thought "official according to who?". :)
"Official" is whatever the BDFL says it is! :-)
So I changed it to mentioning PSF, but that doesn't work either. I guess the current writing as as good as it gets, unless we change "scheduled" to "expected" or something.
On Mon, Jan 11, 2010 at 18:46, MRAB <python@mrabarnett.plus.com> wrote:
"Official" is whatever the BDFL says it is! :-)
Heh, right. So, it should say "Guido wants 2.7 to be the last main version of Python 2, so it probably will be. We promise to release bugfixes it for, like, ages". No need to be needlessly formal. :-D -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
So, it should say "Guido wants 2.7 to be the last main version of Python 2, so it probably will be. We promise to release bugfixes it for, like, ages".
No need to be needlessly formal. :-D
That summarizes my understanding of what Guido said fairly well :-) +1 for putting it into the announcements. Regards, Martin
+1 from me. (With the caveat that "time will tell" is definitely the ultimate answer. Plans may change unexpectedly, even though we don't expect them to.) PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not helpful. But I trust he has ported a lot more code to 3.x than I have personally. Are there other experiences? --Guido On Mon, Jan 11, 2010 at 1:44 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
So, it should say "Guido wants 2.7 to be the last main version of Python 2, so it probably will be. We promise to release bugfixes it for, like, ages".
No need to be needlessly formal. :-D
That summarizes my understanding of what Guido said fairly well :-)
+1 for putting it into the announcements.
Regards, Martin _______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
Guido van Rossum wrote:
+1 from me. (With the caveat that "time will tell" is definitely the ultimate answer. Plans may change unexpectedly, even though we don't expect them to.)
PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not helpful.
That's really because I haven't even attempted to use it. Instead, the software would fall flat on its own when running the test suite in 3.x. IOW, I don't need 2.6 to tell me what might break when I can see 3.x actually breaking. Regards, Martin
On Jan 11, 2010, at 02:55 PM, Guido van Rossum wrote:
PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not helpful. But I trust he has ported a lot more code to 3.x than I have personally. Are there other experiences?
I've only done one small library so far, but it was helpful to me. -Barry
On Mon, Jan 11, 2010 at 23:55, Guido van Rossum <guido@python.org> wrote:
+1 from me. (With the caveat that "time will tell" is definitely the ultimate answer. Plans may change unexpectedly, even though we don't expect them to.)
PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not helpful. But I trust he has ported a lot more code to 3.x than I have personally. Are there other experiences?
It doesn't warn for that many of the unportable problems, but I'm not sure it can warn for them either. It's certainly helpful, just not very much. :) I think the biggest help was added in 2.6.2, and that's warning for old integer division. It will also warn for modules that aren't supported anymore, if I remember correctly, and that's often helpful. But it won't warn for real tricky problems, like binary vs text in strings, and I don't see how it can either. And, I just realized, it doesn't warn for you using cmp or __cmp__ either, and 2to3 won't fix that, so it should actually warn for it. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
And, I just realized, it doesn't warn for you using cmp or __cmp__ either, and 2to3 won't fix that, so it should actually warn for it.
I have a vague recollection that we tried to warn for that and ended up nixing the warning due to vast swarms of false alarms (or because you couldn't write correct 2.x code without triggering it). I'd be happy for someone to prove my recollection wrong though (i.e. by writing a patch that implements such warnings). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Hi Martin,
Of course, the less active fraction of Python contributors may not notice, since they just chose to not contribute (which, of course, is fine). However, asking me to work twice as much as I want to on the project to keep two branches alive is just unfair.
Totally true. Actually as an end-developer I'd say that python 2.x series from a programming perspective is quite good. It doesn't need the addition of a lot of new features imho. So for me, I think too much time spent there would be not yield great benefits.
This has nothing to do with pushing 3.x, but all with managing available manpower and still providing quality software.
Well, we all know your work is super quality. :-) That's not being contested. However, Quality can be measured different ways and it can be assessed in different ways. Quality itself is a subjective thing. The point I'm only making is that if a piece of software doesn't have "new" things added over time, then users can get a reverse impression of a lack of quality. We've all seen where 'internal' quality can increase and user perceptions can decrease. It could be things like improved graphics and things readily apparent to the user. At the moment, I would say that the "internal" quality of the python 2.x series is super high. "external" quality issues such as the packaging dilemma give the user the opposite quality experience. But people are working on that as best they can elsewhere. I'll leave it at that.
This has nothing to do with pushing 3.x, but all with managing available manpower and still providing quality software.
From an ordinary (perphaps ignorant) user perspective there is nothing. Yes, we know if we actually will start
Python 3.x needs more carrots. programming then we will like it more. But my wishes to Santa Claus would be allow the free flow of PEPs for Python 3 packaging. Even encourage it. As an end developer, here's what I'd like from Santa in 2010 to get me to swap to python 3: * get all the packages on pypi tested for python 3 * put a web based package manager in python 3. This would perhaps be based around PIP (keep many people happy) and would look much like the built in web-console that you get with a $200 router. * Incorporate SCM based end-user software installs by adding to python3-stdlib the SCM support packages (cvs,bzr,svn,hg). This would *really* help in the scientific community. * put a web interface on distutils also so that we don't have to use a command line interface. (I want a pic of a smiley girl to great me when I build something - "Are you ready to build now Honey?"). ok - I joke. But the point is made. So, ok, maybe these things aren't about 'code' quality. But rather user experience. Things like these do count also as "quality" via the technical term "perception of quality". If the PEP process is as unblocked as the documentation implies, implying that anybody can contribute to Python 3. Then there shouldn't be any issue. David
David Lyon <david.lyon <at> preisshare.net> writes:
This has nothing to do with pushing 3.x, but all with managing available manpower and still providing quality software.
Python 3.x needs more carrots.
As someone who experiences the difference almost every day, I can say 3.x definitely has enough carrots for me. The simple fact that I will be able to raise exceptions with non-ASCII error messages without having to workaround a hopelessly broken conversion/reporting logic is a huge improvement. And that's only a small part of the picture. Regards Antoine.
Antoine writes:
As someone who experiences the difference almost every day, I can say 3.x definitely has enough carrots for me. The simple fact that I will be able to raise exceptions with non-ASCII error messages without having to workaround a hopelessly broken conversion/reporting logic is a huge improvement. And that's only a small part of the picture.
In no way could I disagree with you. Ascii works fine for us here - but I guess we're lucky. Just keep pushing python 3 and have a nice day.. David
David Lyon <david.lyon <at> preisshare.net> writes:
This has nothing to do with pushing 3.x, but all with managing available manpower and still providing quality software.
Python 3.x needs more carrots.
I'd be happy to move UpLib to Python 3, when the various packages that I need are also on Python 3. And that depresses me to think about. I need Medusa ReportLab PyLucene Email Vobject Mutagen Pyglet Hachoir Win32 I'm on the mailing lists for a lot of these, and the only one that I know is thinking about Python 3 is Email. I'd expect Win32 and PIL to also be thinking about it, but I haven't heard anything. Bill
David Lyon wrote:
This has nothing to do with pushing 3.x, but all with managing available manpower and still providing quality software.
Python 3.x needs more carrots.
As Guido has said a few times, the gains are far greater for *new* Python developers than they are for existing ones. Existing developers have to unlearn old habits and wait for libraries they already use to get ported. New developers can just get started with a much cleaner language. They don't have as rich a 3rd party ecosystem on Python 3 as they would on Python 2.x at this point in time, but unlike existing developers they also have the luxury of cherry-picking just those packages that already have Python 3 support. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick wrote:
This has nothing to do with pushing 3.x, but all with managing available manpower and still providing quality software.
Python 3.x needs more carrots.
As Guido has said a few times, the gains are far greater for *new* Python developers than they are for existing ones.
Well both you and Guido are most likely 100% correct. :-)
They don't have as rich a 3rd party ecosystem on Python 3 as they would on Python 2.x at this point in time, but unlike existing developers they also have the luxury of cherry-picking just those packages that already have Python 3 support.
Most likely. I wouldn't want to say anything to discourage people from going to python 3. In other languages, I have much experience of making the jump to 'a whole new world'. It's unsettling at first, but after that, you suddenly find the new model has a better turbo than the last and you're at the next corner faster than you can think. So it's all good. But I still maintain Python 3.0 needs more carrots. For example, if mercurial or any other cool lib gets added to python 3 (and I can name a few that should go in python 3) then they should be added to python 3 and not to python 2.x They would serve as good carrots. Make fresh the python 3 stdlib and preserve the python 2.x stdlib. I really think we are somewhat short on resources to do what Guido has asked about bringing python up to CPAN level with respect to packages. We're starting a long way back with horses and swords and trying to catch a well fed and greased modern machine.. I'm sure we can get a modern package testbot operational for python. But I wish those who were complaining about the packaging problem so much could throw some money at the problem instead of moaning about it. As is done on other open-source projects. Some organisation would be beneficial. Finding funds so that a small group of people could work on the problem would be a great boost to forward progress. I just think python packaging needs six months of that to repair the years and years of neglect and stagnation. Even if it is only beer and bus fare money. It just needs a temporary shot of adrenalin in the arm.. so to speak.. Regards David
Neil Schemenauer writes:
On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
If people start taking the carrots we have added to 3.x and backporting them to keep the 2.x series alive you are essentially making the 3.x DOA by negating its benefits which I personally don't agree with.
Well, I think it's *worse* than that, and I don't think you really mean "DOA", anyway. (Feel free to correct me, of course.) The problem I see with backporting lots of stuff, and/or adding new features that aren't in 3.0, to 2.x is that it will make 2.x even cruftier, when it was already crufty enough that Guido (and almost all of python-dev) bit the bullet and said "backward compatibility is no excuse for keeping something in 3.0". That surely means that a lot of python-dev denizens will declare non-support 2.x for x > 7. It's not going to be the gradual migration we've seen over the past few months as active people start to spend more and more time on 3 vs. 2; it will be a watershed. Especially if these are new features merged from outside that the "small active segment" doesn't know anything about. From the users' point of view, that amounts to a *fork*, even if it's internal and "friendly".
I think we have got to the heart of our disagreement. Assume that some superhuman takes all the backwards compatible goodies from 3.x and merges them into 2.x.
Isn't that a bit ridiculous? I just don't see any evidence that anything like that is going to happen. Worse, if we *assume* it will happen, I don't see any way to assess whether (1) Python 3 goes belly up, (2) there's an effective fork confusing the users and draining the energy of python-dev, or (3) everybody goes "wow!" because it's so cool that everybody wants to keep maintaining an extra 3 branches indefinitely. My opinion is that given the clear direction the "small active segment" is going, telling the users anything but what Brett proposed is disinformation.
I guess I have more confidence in Python 3 than you do. I don't see why Python 2.x needs to be artificially limited so that Python 3 can benefit.
It's not for Python 3, which you, I, and I'm pretty sure Brett-in-his- heart-of-hearts agree can take care of itself because it is *better* than Python 2. It's for Python, and for the Python community.
I would guess over 99% of all Python code written doesn't run on Python 3. Given that, I think it is premature to close the door on new major versions of Python 2.x. Also, we as a project should be careful not to present the image that Python 2.x will not be supported in the future.
Why that? It is a fact: 2.x will not be supported, in some future. Should we lie to users?
After the Python 2.7 release, the focus of Python development will be on Python 3. There will continue to be maintainance releases of Python 2.x.
It shouldn't say that, because it wouldn't be true. Regards, Martin
Neil Schemenauer wrote:
In order to avoid wasted development effort, it would be prudent to announce that unless a 2.8 release manager steps up, whatever is committed to the 2.x branch after the 2.7 release may never get released.
The announcement is precisely to avoid the situation where people commit new features to the 2.x main line of development (after the 2.7 maintenance branch is created) in the expectation that they will be released as part of a hypothetical 2.8 release. Whether that info needs to be in each and every 2.7 announcement... probably not. It isn't really info for users of Python, just for developers of Python. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
The announcement is precisely to avoid the situation where people commit new features to the 2.x main line of development (after the 2.7 maintenance branch is created) in the expectation that they will be released as part of a hypothetical 2.8 release.
Whether that info needs to be in each and every 2.7 announcement... probably not. It isn't really info for users of Python, just for developers of Python.
I think the announcement is indeed also for the users, and I would prefer it to stay in the release announcements, so that people will know for sure (and speak up) before the 2.7 release happens. As for decisions: I don't think there was an official BDFL pronouncent, but I recall Guido posting a message close to that, proposing that 2.7 will be a release that will see bug fix releases for an indefinite period of time (where indefinite != infinite). This was shortly after him proposing that perhaps we shouldn't make a 2.7 release at all, and stop at 2.6. As for such a decision giving a bad light on Python: I don't think that will be the case. Instead, I hear many users surprised for how long we have been maintaining to parallel versions - "that must have taken a lot of effort". So everybody will likely understand that enough is enough. Regards, Martin
On Jan 10, 2010, at 6:07 PM, Martin v. Löwis wrote:
As for decisions: I don't think there was an official BDFL pronouncent, but I recall Guido posting a message close to that, proposing that 2.7 will be a release that will see bug fix releases for an indefinite period of time (where indefinite != infinite). This was shortly after him proposing that perhaps we shouldn't make a 2.7 release at all, and stop at 2.6.
IMO, the focus for Python 2.7 (and beyond) must be on helping people transition to Python 3. That should be the reason why a 2.7 is released and, what should dictate whether a 2.8 is necessary. Maybe everything people need (except manpower and round tuits) is already there. I was pleasantly surprised to find that Distribute supports automatically running 2to3 at install time for Python packages. This allowed me to "port" a recent (admittedly small) package to Python 3 by making it "python2.6 -3" clean and adding a couple of attributes to my setup.py[1]. I don't know how widely that feature's known, but I think it's *huge*, and exactly what we need to be doing. The more we can make it easy for people to port their Python 2 code to Python 3, and to support that with one code base, the quicker we'll get to a predominantly Python 3 world. So the question we should be asking is: what's missing from Python 2.7 to help with this transition? If we can't get it into 2.7, then why, and would pushing it back to 2.8 help at all? -Barry [1] modulo a bug in Distribute that caused doctest in separate files to not be used when running under Python 3.
So the question we should be asking is: what's missing from Python 2.7 to help with this transition?
Wrt. the distribute feature you've noticed: Python 3.0 already supports that in distutils. So from day one of Python 3.x, you could have used that approach for porting Python code. I had been promoting it ever since, but it's taking up only slowly, partially because it has competition in the approaches "burn the bridges" (i.e. convert to 3.x once, and then have two code bases, or abandon 2.x), and "avoid 2to3" (i.e. try to write code that works in both 2.x and 3.x unmodified).
If we can't get it into 2.7, then why, and would pushing it back to 2.8 help at all?
I've done a fair bit of 3.x porting, and I'm firmly convinced that 2.x can do nothing: a) telling people that they have to move to 2.6 first actually hurts migration, instead of helping, because it implies to them that they have to drop old versions (e.g. 2.3.) - just because they had *always* dropped old versions before supporting new ones. b) IMO, people also don't gain much by first migrating to 2.6. In principle, it gives them the opportunity to get py3k warnings. However, I haven't heard a single positive report where these warnings have actually helped people in porting. Yours is the first report saying that you followed the official guideline, but you didn't state whether doing so actually helped (or whether you just ported to 2.6 because the guideline told you to). c) whatever 2.7 does (except perhaps for the warnings), it won't be useful to applications, because they couldn't use it, anyway: they need to support 2.4 and 2.5, and it won't have any of the gimmicks people come up with for 2.7. Adding gimmicks to 2.7 might actually hurt porting: people may have to special-case 2.7 because their work-arounds for older versions may break in 2.7 (e.g. testing whether a name is *not* defined, when it becomes defined in 2.7), plus it gives them an incentive to not port yet until they can drop support for anything before 2.7. Inherently, 2.8 can't improve on that. Regards, Martin
"Martin v. Löwis" wrote: [...]
I've done a fair bit of 3.x porting, and I'm firmly convinced that 2.x can do nothing: [...] Inherently, 2.8 can't improve on that.
I agree that there are limitations like the ones you've listed, but I disagree with your conclusion. Maybe you assume that it's just as hard to move to 2.8 (using the py3k backports not available in say 2.5) as it is to 3.x? But a hypothetical 2.8 would also give people a way to move closer to py3k without giving up on using all their 2.x-only dependencies. I think it's much more likely that libraries like Twisted can support 2.8 in the near future than 3.x. Then, when all of your dependencies (or viable alternatives to those dependencies) are available for 3.x, you'll have an easier transition if you can start from a 2.x with fewer differences in features. Fundamentally the more 2.x can converge on 3.x, the easier it will be for users to make the leap, because it will be a smaller leap. The longer the 2.x series lives, the more these newer 2.x versions like 2.7 and maybe even 2.8 will be available on common platforms for people to depend upon as minimum versions, which means that as time goes by they can depend on a version that's closer to 3.x. And so again, the leap becomes easier to make. So to me it's pretty clear that 2.8 *can* improve the transition path to 3.x. It may or may not be a worthwhile use of effort for python-dev to make 2.8, but that's different to saying it's inherently pointless. -Andrew.
Andrew Bennetts <andrew <at> bemusement.org> writes:
But a hypothetical 2.8 would also give people a way to move closer to py3k without giving up on using all their 2.x-only dependencies. I think it's much more likely that libraries like Twisted can support 2.8 in the near future than 3.x.
I don't think a 2.8 could make you much closer to 3.x. AFAICT, every possible way to ease transition to 3.x will already be in 2.7, or almost. But perhaps I'm lacking imagination. Regards Antoine.
On Tue, Jan 12, 2010 at 01:07, Andrew Bennetts <andrew@bemusement.org> wrote:
But a hypothetical 2.8 would also give people a way to move closer to py3k without giving up on using all their 2.x-only dependencies. I think it's much more likely that libraries like Twisted can support 2.8 in the near future than 3.x.
When 2.7 was discussed several people agreed that 2.7 should include as much 3.x stuff as possible to ease transition. That turned out to not be very much, so I'm not sure there is more. :) Unless of course, 2.8 starts including more of the refactored libraries, but that's a very minor issue in porting, so it won't help much. To really help, it needs to start implement things that break backwards compatibility. That would be weird. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
[...]
I've done a fair bit of 3.x porting, and I'm firmly convinced that 2.x can do nothing: [...] Inherently, 2.8 can't improve on that.
I agree that there are limitations like the ones you've listed, but I disagree with your conclusion. Maybe you assume that it's just as hard to move to 2.8 (using the py3k backports not available in say 2.5) as it is to 3.x?
Not at all, no. I'd rather expect that code that runs on 2.7 will run on 2.8 unmodified.
But a hypothetical 2.8 would also give people a way to move closer to py3k without giving up on using all their 2.x-only dependencies.
How so? If they use anything that is new in 2.8, they *will* need to drop support for anything before it, no???
I think it's much more likely that libraries like Twisted can support 2.8 in the near future than 3.x.
Most likely, Twisted "supports" 2.8 *today* (hopefully). But how does that help Twisted in moving to 3.2?
Then, when all of your dependencies (or viable alternatives to those dependencies) are available for 3.x, you'll have an easier transition if you can start from a 2.x with fewer differences in features.
But you won't *have* fewer differences. Just because your code runs on 2.8 doesn't mean it will stop running on 2.3 (if you have a need for that). This doesn't get you any closer - you can't use any of the 2.8 features as long as you have to support older versions of Python.
Fundamentally the more 2.x can converge on 3.x, the easier it will be for users to make the leap, because it will be a smaller leap.
No, it won't. It might be if people move to 2.8 *and* drop 2.5, but they likely won't.
The longer the 2.x series lives, the more these newer 2.x versions like 2.7 and maybe even 2.8 will be available on common platforms for people to depend upon as minimum versions, which means that as time goes by they can depend on a version that's closer to 3.x.
No, that's incorrect. Suppose 2.7 is the last 2.x release, to be released in 2010. Then, in 2015, it may be that everybody has migrated to 2.7, which then is a common platform. If you release 2.8 in 2012, then, in 2015, people will be split between 2.7 and 2.8, and so there won't be a common platform before 2017. So stopping 2.x development *earlier* will also give us a common platform earlier. Regareds, Martin
"Martin v. Löwis" wrote: [...]
But a hypothetical 2.8 would also give people a way to move closer to py3k without giving up on using all their 2.x-only dependencies.
How so? If they use anything that is new in 2.8, they *will* need to drop support for anything before it, no???
I think it's much more likely that libraries like Twisted can support 2.8 in the near future than 3.x.
Most likely, Twisted "supports" 2.8 *today* (hopefully). But how does that help Twisted in moving to 3.2?
I'm not talking about Twisted moving to 3.x (FWIW, I think the only movement there so far is some patches for some -3 warnings). The situation I'm describing is a project X that: (a) has 2.x-only dependencies, and (b) would like to be as close as possible to 3.x (because they like the new features and/or want to be as ready as possible to jump when (a) is fixed). So just because project X depends on e.g. Twisted, and that Twisted in turn still supports 2.4, doesn't mean that X cannot move to 2.8, and doesn't mean it would get no benefit from doing so. [...]
No, it won't. It might be if people move to 2.8 *and* drop 2.5, but they likely won't.
But this is my point. I think they would as an intermediate step to jumping to 3.x (which also requires dropping 2.5, after all!), if for some reason they cannot yet jump to 3.x, such as a 2.x-only dependency. -Andrew.
I'm not talking about Twisted moving to 3.x (FWIW, I think the only movement there so far is some patches for some -3 warnings). The situation I'm describing is a project X that:
(a) has 2.x-only dependencies, and (b) would like to be as close as possible to 3.x (because they like the new features and/or want to be as ready as possible to jump when (a) is fixed).
This assumes that jumping to 3.x is easier if you are closer to it. Please trust me that this is not the case.
No, it won't. It might be if people move to 2.8 *and* drop 2.5, but they likely won't.
But this is my point. I think they would as an intermediate step to jumping to 3.x (which also requires dropping 2.5, after all!), if for some reason they cannot yet jump to 3.x, such as a 2.x-only dependency.
No, and no. No: it's not an intermediate step, and no, supporting 3.x does *not* require dropping 2.5. Regards, Martin
On 1/12/2010 5:04 PM, "Martin v. Löwis" wrote:
But you won't *have* fewer differences. Just because your code runs on 2.8 doesn't mean it will stop running on 2.3 (if you have a need for that). This doesn't get you any closer - you can't use any of the 2.8 features as long as you have to support older versions of Python.
Fundamentally the more 2.x can converge on 3.x, the easier it will be for users to make the leap, because it will be a smaller leap.
No, it won't. It might be if people move to 2.8 *and* drop 2.5, but they likely won't.
The longer the 2.x series lives, the more these newer 2.x versions like 2.7 and maybe even 2.8 will be available on common platforms for people to depend upon as minimum versions, which means that as time goes by they can depend on a version that's closer to 3.x.
No, that's incorrect. Suppose 2.7 is the last 2.x release, to be released in 2010. Then, in 2015, it may be that everybody has migrated to 2.7, which then is a common platform.
If you release 2.8 in 2012, then, in 2015, people will be split between 2.7 and 2.8, and so there won't be a common platform before 2017.
Just like people today may need to work with both 2.5 and 2.6, or privately backport 2.6 bugfixes to 2.5.
So stopping 2.x development *earlier* will also give us a common platform earlier.
With years of bug fixes and hence high quality.
On 12 Jan, 10:04 pm, martin@v.loewis.de wrote:
[...]
I've done a fair bit of 3.x porting, and I'm firmly convinced that 2.x can do nothing: [...] Inherently, 2.8 can't improve on that.
I agree that there are limitations like the ones you've listed, but I disagree with your conclusion. Maybe you assume that it's just as hard to move to 2.8 (using the py3k backports not available in say 2.5) as it is to 3.x?
Not at all, no. I'd rather expect that code that runs on 2.7 will run on 2.8 unmodified.
But a hypothetical 2.8 would also give people a way to move closer to py3k without giving up on using all their 2.x-only dependencies.
How so? If they use anything that is new in 2.8, they *will* need to drop support for anything before it, no???
I think it's much more likely that libraries like Twisted can support 2.8 in the near future than 3.x.
Most likely, Twisted "supports" 2.8 *today* (hopefully). But how does that help Twisted in moving to 3.2?
I'm not reading this thread carefully enough to make any arguments on either side, but I can contribute a fact. Twisted very likely does not support 2.8 today. I base this on the fact that Twisted does not support 2.7 today, and I expect 2.8 will be more like 2.7 than it will be like 2.3 - 2.6 (which Twisted does support). When I say "support" here, I mean "all of the Twisted unit tests pass on it". Jean-Paul
On Jan 11, 2010, at 10:42 PM, Martin v. Löwis wrote:
Wrt. the distribute feature you've noticed: Python 3.0 already supports that in distutils. So from day one of Python 3.x, you could have used that approach for porting Python code. I had been promoting it ever since, but it's taking up only slowly, partially because it has competition in the approaches "burn the bridges" (i.e. convert to 3.x once, and then have two code bases, or abandon 2.x), and "avoid 2to3" (i.e. try to write code that works in both 2.x and 3.x unmodified).
Interesting. The only reason I never used it before is because I didn't know about it. Am I alone? Maybe I'm projecting my own preferences, but it seems to me that supporting both Python 2 and 3 from the same code base would be a very powerful way to enable a large amount of existing code to support Python 3. I'm certainly going to do this from now on with all the libraries I maintain. I don't have any cycles to write code twice and I can't abandon Python 2 yet. I'm skeptical that code can work unmodified in both 2 and 3 without 2to3. As an example, the one library I've already ported used a metaclass. I don't see any way to specify that the metaclass should be used in a portable way. In Python 2.6 it's: class Foo: __metaclass__ = Meta and in Python 3 it's: class Foo(metaclass=Meta): 2to3 made that pain go away.
I've done a fair bit of 3.x porting, and I'm firmly convinced that 2.x can do nothing:
a) telling people that they have to move to 2.6 first actually hurts migration, instead of helping, because it implies to them that they have to drop old versions (e.g. 2.3.) - just because they had *always* dropped old versions before supporting new ones.
Is it just an implication, or is it reality? I have yet to try to support older versions of Python and also support Python 3. (The one package I've done this with so far only supports Python 2.6.)
b) IMO, people also don't gain much by first migrating to 2.6. In principle, it gives them the opportunity to get py3k warnings. However, I haven't heard a single positive report where these warnings have actually helped people in porting. Yours is the first report saying that you followed the official guideline, but you didn't state whether doing so actually helped (or whether you just ported to 2.6 because the guideline told you to).
Python 2.6 has other useful features, which I want to take advantage of, so getting py3k warnings is a bonus. Running 'python2.6 -3 setup.py test' over my code did in fact help clean up a couple of problems. Seems like a good first step when considering Python 3 support to me.
c) whatever 2.7 does (except perhaps for the warnings), it won't be useful to applications, because they couldn't use it, anyway: they need to support 2.4 and 2.5, and it won't have any of the gimmicks people come up with for 2.7. Adding gimmicks to 2.7 might actually hurt porting: people may have to special-case 2.7 because their work-arounds for older versions may break in 2.7 (e.g. testing whether a name is *not* defined, when it becomes defined in 2.7), plus it gives them an incentive to not port yet until they can drop support for anything before 2.7.
Inherently, 2.8 can't improve on that.
I'm not so sure. Yes, as a package maintainer there are older versions to think about, but time moves on for everyone (hopefully :). By the time 2.8 is released, what will be the minimum version of Python provided by most OS vendors (where the majority of Python users probably get their 'python')? I guess some people will have to support everything from Python 2.3 to 2.8 but you're talking supporting something like a spread of 7 years of Python versions. What other platform do you support for 7 years? Even Ubuntu long term support (LTS) releases only live for 5 years and even then, newer Pythons are often back ported. Or if not, then who cares? You're not going to use a newer version of a library on an LTS anyway. I'm not necessarily saying that justifies a 2.8 release. I'm just asking how we can make it easier for people to port to Python 3. The automatic 2to3 has already made it easier for me to port one library to Python 3 because I barely had to even think about it. Maybe that's enough. -Barry
On Mon, Jan 11, 2010 at 7:11 PM, Barry Warsaw <barry@python.org> wrote:
As an example, the one library I've already ported used a metaclass. I don't see any way to specify that the metaclass should be used in a portable way. In Python 2.6 it's:
class Foo: __metaclass__ = Meta
and in Python 3 it's:
class Foo(metaclass=Meta):
2to3 made that pain go away.
[sidebar] 1) the metaclass fixer was a PITA to implement. 2) 95% of __metaclass__ definitions searchable via google code were of the "__metaclass__ = type" variety. The 2to3 patch exists only because of the few other uses. 3) 100% of the module level assignments in public projects were the "__metaclass__ = type" variety which is why there isn't a fixer for that. Also, a fixer would have been really, really ugly (munge every class definition in this module because there is a top level assignment). -Jack
2010/1/11 Jack Diederich <jackdied@gmail.com>:
On Mon, Jan 11, 2010 at 7:11 PM, Barry Warsaw <barry@python.org> wrote:
As an example, the one library I've already ported used a metaclass. I don't see any way to specify that the metaclass should be used in a portable way. In Python 2.6 it's:
class Foo: __metaclass__ = Meta
and in Python 3 it's:
class Foo(metaclass=Meta):
2to3 made that pain go away.
[sidebar] 1) the metaclass fixer was a PITA to implement.
Does this make it any less useful, though? :) -- Regards, Benjamin
On Jan 11, 2010, at 10:53 PM, Jack Diederich wrote:
3) 100% of the module level assignments in public projects were the "__metaclass__ = type" variety which is why there isn't a fixer for that. Also, a fixer would have been really, really ugly (munge every class definition in this module because there is a top level assignment).
And almost certainly unnecessary. IME, those are all to easily make bare class definitions new style in Python 2. -Barry
On Mon, Jan 11, 2010 at 4:11 PM, Barry Warsaw <barry@python.org> wrote:
As an example, the one library I've already ported used a metaclass. I don't see any way to specify that the metaclass should be used in a portable way. In Python 2.6 it's:
class Foo: __metaclass__ = Meta
and in Python 3 it's:
class Foo(metaclass=Meta):
2to3 made that pain go away.
Actually there's a solution to this one too: FooBase = Meta('FooBase', (), {}) class Foo(FooBase): ... That should work in Python 2.X and 3.X. I've got argparse running on Python 2.3-3.1, and the changes were pretty easy. You can see them all in the revision here: http://code.google.com/p/argparse/source/detail?r=12 I have aspirations of putting all of the tricks I learned up up on the Wiki somewhere, but I just haven't had the time. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Jan 11, 2010, at 09:57 PM, Steven Bethard wrote:
Actually there's a solution to this one too:
FooBase = Meta('FooBase', (), {}) class Foo(FooBase): ...
That should work in Python 2.X and 3.X.
Ugly, but good call! :)
I've got argparse running on Python 2.3-3.1, and the changes were pretty easy. You can see them all in the revision here:
http://code.google.com/p/argparse/source/detail?r=12
I have aspirations of putting all of the tricks I learned up up on the Wiki somewhere, but I just haven't had the time.
The more resources we can provide people, both in code and in documentation, the better. Thanks! -Barry
On 12/01/2010 12:16, Barry Warsaw wrote:
On Jan 11, 2010, at 09:57 PM, Steven Bethard wrote:
Actually there's a solution to this one too:
FooBase = Meta('FooBase', (), {}) class Foo(FooBase): ...
That should work in Python 2.X and 3.X.
Ugly, but good call! :)
There are all sorts of tricks. For example you can do exception handling that works with pre-2.6 syntax and 3.0 with a bare except and using sys.exc_info. It is horrible, but acceptable for short pieces of code (I have a couple of small modules that do this). I haven't yet tried converting larger code-bases to Python 3, but I think the workflow advocated by Martin is greatly preferable to the hacks and tricks needed to make the same codebase run under 2 & 3. Michael
I've got argparse running on Python 2.3-3.1, and the changes were pretty easy. You can see them all in the revision here:
http://code.google.com/p/argparse/source/detail?r=12
I have aspirations of putting all of the tricks I learned up up on the Wiki somewhere, but I just haven't had the time.
The more resources we can provide people, both in code and in documentation, the better.
Thanks! -Barry
_______________________________________________ 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/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Tue, Jan 12, 2010 at 04:29, Michael Foord <fuzzyman@voidspace.org.uk>wrote:
On 12/01/2010 12:16, Barry Warsaw wrote:
On Jan 11, 2010, at 09:57 PM, Steven Bethard wrote:
Actually there's a solution to this one too:
FooBase = Meta('FooBase', (), {}) class Foo(FooBase): ...
That should work in Python 2.X and 3.X.
Ugly, but good call! :)
There are all sorts of tricks. For example you can do exception handling that works with pre-2.6 syntax and 3.0 with a bare except and using sys.exc_info. It is horrible, but acceptable for short pieces of code (I have a couple of small modules that do this).
I haven't yet tried converting larger code-bases to Python 3, but I think the workflow advocated by Martin is greatly preferable to the hacks and tricks needed to make the same codebase run under 2 & 3.
In other words we need to pull together a HOWTO for Python source like the one for extension modules that Benjamin wrote and make it rather prominently linked from the Python 3 documentation index page. -Brett
On Tue, Jan 12, 2010 at 01:11, Barry Warsaw <barry@python.org> wrote:
Interesting. The only reason I never used it before is because I didn't know about it. Am I alone?
Maybe not, but the Distribute feature is there because IMO the distutils feature by itself isn't particularily useful. You need to write your own distutils extensions, in practice, and they are not trivial. Distribute has simply done it for you. :)
I'm skeptical that code can work unmodified in both 2 and 3 without 2to3. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Maybe not, but the Distribute feature is there because IMO the distutils feature by itself isn't particularily useful. You need to write your own distutils extensions, in practice, and they are not trivial.
I wouldn't say that. My Django port works with bare distutils (as does Django itself), and it works fine. That distribute had to redo it is only because setuptools *replaces* the build_py command, as does the 2to3 support in distutils. So only if you have a different build_py already, you can't use what is in distutils. Regards, Martin
On Tue, Jan 12, 2010 at 22:56, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Maybe not, but the Distribute feature is there because IMO the distutils feature by itself isn't particularily useful. You need to write your own distutils extensions, in practice, and they are not trivial.
I wouldn't say that. My Django port works with bare distutils (as does Django itself), and it works fine.
That distribute had to redo it is only because setuptools *replaces* the build_py command, as does the 2to3 support in distutils. So only if you have a different build_py already, you can't use what is in distutils.
Yeah, you are right, I misremembered. The actual additional feature is the support for the test command. Testing under Python 2 and 3 without it is annoying. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
a) telling people that they have to move to 2.6 first actually hurts migration, instead of helping, because it implies to them that they have to drop old versions (e.g. 2.3.) - just because they had *always* dropped old versions before supporting new ones.
Is it just an implication, or is it reality?
That's only the implication. However, this was precisely the dialogue when talking to Django. If you start with "start supporting 2.6", the immediate response, without listening further, was, "ok, wait until we drop 2.3, which will be in Spring 2009" (it has happened by now, IIUC). Then explain it to the individual you are talking to, wait for the next developer of the project step along, and see how he brings up the very same line of thinking (supporting new versions == dropping support for old versions). I think only part of that comes from the maintenance burden. The other part is that they *want* to drop support for old versions, so that they can eventually start using new features (e.g. generator expressions). So they welcome the requirement to support new versions as an excuse to drop old ones ("it is obvious that you have to drop 2.3 to support 3.2"). However, their users then won't let them drop old versions.
b) IMO, people also don't gain much by first migrating to 2.6. In principle, it gives them the opportunity to get py3k warnings. However, I haven't heard a single positive report where these warnings have actually helped people in porting. Yours is the first report saying that you followed the official guideline, but you didn't state whether doing so actually helped (or whether you just ported to 2.6 because the guideline told you to).
Python 2.6 has other useful features, which I want to take advantage of
I think you are a minority with that, being able to actually use the 2.6 features already. Many projects can't, as they have to support at least 2.4 still (so the with statement is right out).
Inherently, 2.8 can't improve on that.
I'm not so sure. Yes, as a package maintainer there are older versions to think about, but time moves on for everyone (hopefully :). By the time 2.8 is released, what will be the minimum version of Python provided by most OS vendors (where the majority of Python users probably get their 'python')?
"Current" Linux distributions will have 2.6 then. "Old" installations will have 2.4.
I guess some people will have to support everything from Python 2.3 to 2.8 but you're talking supporting something like a spread of 7 years of Python versions. What other platform do you support for 7 years?
I think 2.3 will really be gone by the time 2.8 might get released. Even with 2.7, you'd end up with a span of seven years, though. Python had been supporting Windows 95 for more than 7 years (I think rather 9 or 10), likewise Windows 3.1 before that. Python 2.7 will likely still support Windows 2000, which then will be ten years old. Solaris support will probably go back to Solaris 2.6, which will be 13 years old when Python 2.7 gets released. It's only the Linux (and OS X) releases that move so quickly. Regards, Martin
On 12/01/2010 21:53, "Martin v. Löwis" wrote:
a) telling people that they have to move to 2.6 first actually hurts migration, instead of helping, because it implies to them that they have to drop old versions (e.g. 2.3.) - just because they had *always* dropped old versions before supporting new ones.
Is it just an implication, or is it reality?
That's only the implication. However, this was precisely the dialogue when talking to Django. If you start with "start supporting 2.6", the immediate response, without listening further, was, "ok, wait until we drop 2.3, which will be in Spring 2009" (it has happened by now, IIUC).
Then explain it to the individual you are talking to, wait for the next developer of the project step along, and see how he brings up the very same line of thinking (supporting new versions == dropping support for old versions).
I think only part of that comes from the maintenance burden. The other part is that they *want* to drop support for old versions, so that they can eventually start using new features (e.g. generator expressions). So they welcome the requirement to support new versions as an excuse to drop old ones ("it is obvious that you have to drop 2.3 to support 3.2"). However, their users then won't let them drop old versions.
I agree with Martin that the *perception* is that to use Python 2.6 to help you port to Python 3 you have to be willing to drop support for earlier versions of Python.
b) IMO, people also don't gain much by first migrating to 2.6. In principle, it gives them the opportunity to get py3k warnings. However, I haven't heard a single positive report where these warnings have actually helped people in porting. Yours is the first report saying that you followed the official guideline, but you didn't state whether doing so actually helped (or whether you just ported to 2.6 because the guideline told you to).
Python 2.6 has other useful features, which I want to take advantage of
I think you are a minority with that, being able to actually use the 2.6 features already. Many projects can't, as they have to support at least 2.4 still (so the with statement is right out).
Well, the IronPython community has almost completely moved over to IronPython 2.6. :-) We tend to ship our Python runtime with our applications though. As it happens I'm now working with CPython on the server (Python 2.5) and IronPython in the browser where we are using 2.6. The new property feature is nice, as is having with without a __future__ import. All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Michael Foord wrote:
I agree with Martin that the *perception* is that to use Python 2.6 to help you port to Python 3 you have to be willing to drop support for earlier versions of Python.
Note that increased 3.x compatibility in the most recent 2.x release will always help in two scenarios: 1. New projects that want to use 2.x only libraries but want to be ready for the Py3k transition in their own code (e.g. new 2.7 features like set literals, dict and set comprehensions and the view* dict methods can be translated far more cleanly by 2to3 than the closest comparable 2.6 code). 2. Similarly new projects that use a 3.x trunk can be more readily translated to a 2.7 version with 3to2, whereas some constructs may be difficult to recreate in earlier Python versions. I would expect this to be significantly less common then the first scenario though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Note that increased 3.x compatibility in the most recent 2.x release will always help in two scenarios:
1. New projects that want to use 2.x only libraries but want to be ready for the Py3k transition in their own code (e.g. new 2.7 features like set literals, dict and set comprehensions and the view* dict methods can be translated far more cleanly by 2to3 than the closest comparable 2.6 code).
Of these, I can only see this being the case of the view* methods. Why would set literals allow for code that more cleanly translates to 3.x? Suppose you write f = set((1,2,3)) in 2.6. That code will work *exactly* the same way in 3.1, no translation needed at all. Likewise for dict and set comprehensions: the code is as cleanly translated in the 2.7 form as it is in any prior form (ie. no modifications). As for view* methods: there is one important exception where the 2.6 equivalent is as cleanly translated as a view method: for key in D: action This is a more modern equivalent for iterating over D.keys(), so if your code still does the latter, just change it to the former (requires Python 2.2). I'd claim that this is the dominant case of traversing a dictionary (probably followed by iterating over .items()). So while it is true that only view* can be transformed correctly, I'd claim that this is an infrequent issue.
2. Similarly new projects that use a 3.x trunk can be more readily translated to a 2.7 version with 3to2, whereas some constructs may be difficult to recreate in earlier Python versions.
That may be true, but is besides the point here: the issue was whether a 2.8 release might help in migrating to 3.x. People who follow this approach already have 3.x code. Whether they would rather port to 2.8 only, and get that work with little effort, or whether they would port to 2.5 and later, and put in more work, I don't know - I guess we would have to ask these people. I would expect that they prefer if 2.x died rather sooner than later, because they can then stop supporting it. Regards, Martin
I propose that the 2.x branch be treated like 2.x.y branches: as long as there is sufficient volunteer labour, it should continue to live. In order to avoid wasted development effort, it would be prudent to announce that unless a 2.8 release manager steps up, whatever is committed to the 2.x branch after the 2.7 release may never get released.
I think it's more difficult than that. It also takes developer effort to *commit* to the trunk. So if the trunk continued to live, would it still be ok if I closed a 2.x feature request as "won't fix", or only committed the new feature to the 3.x branch? As for old branches: they *don't* live in the way you claim (i.e. remain open with changes potentially just not released). Instead, at some point, they are frozen to bug-fix only, then to security-fix only, and then to no change at all. Regards, Martin
On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote:
[...] would it still be ok if I closed a 2.x feature request as "won't fix", or only committed the new feature to the 3.x branch?
Yes. Non-bugfix development on 2.x would optional (i.e. done by people who want to spend the time). Since language changes are now out (an initiative I completely support), the majority of non-bugfix changes would be optimizations and platform porting. Regards, Neil
Neil Schemenauer wrote:
On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote:
[...] would it still be ok if I closed a 2.x feature request as "won't fix", or only committed the new feature to the 3.x branch?
Yes. Non-bugfix development on 2.x would optional (i.e. done by people who want to spend the time).
I think *that* would give a very bad impression of Python. Depending whom you deal with, the new feature you want may or may not get added to the code base. Contributors would feel even more stranded than they do now, where it may take several years to get a patch reviewed, as you then could submit a patch, and pray that a comitter reviews it who believes in future 2.x releases. The point of setting policies is that it gives every user (contributors, committers, and "end-user" developers) a reliable foundation for expectations. Regards, Martin
Neil Schemenauer, 11.01.2010 05:17:
On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote:
[...] would it still be ok if I closed a 2.x feature request as "won't fix", or only committed the new feature to the 3.x branch?
Yes. Non-bugfix development on 2.x would optional (i.e. done by people who want to spend the time).
Note that there's also the time it takes to make a release (usually involving at least one beta release), plus the possibility of introducing bugs while adding new features or even while fixing agreed bugs. All of this takes time in addition to the time people might want to invest in 'real' development on the 2.x trunk. Stefan
On Sat, Jan 9, 2010 at 18:29, Benjamin Peterson <benjamin@python.org> wrote:
Please consider trying Python 2.7 with your code and reporting any bugs you may
I ran the Mercurial test suite on current trunk, and it worked alright. There was a small issue with the fact that mimetypes got fooled by the lack of ImportError from _winreg (which I solved by blacklisting _winreg in demandimport), and one test fails likely because of a change in MIME handling. Will look into that. So the state of trunk looks rather solid from where I sit. Cheers, Dirkjan
participants (25)
-
"Martin v. Löwis" -
Andrew Bennetts -
Antoine Pitrou -
Arc Riley -
Barry Warsaw -
Benjamin Peterson -
Bill Janssen -
Brett Cannon -
Chris McDonough -
David Lyon -
Dirkjan Ochtman -
exarkun＠twistedmatrix.com -
Guido van Rossum -
Jack Diederich -
Karen Tracey -
Lennart Regebro -
Michael Foord -
MRAB -
Neil Schemenauer -
Nick Coghlan -
Stefan Behnel -
Stephen J. Turnbull -
Steven Bethard -
Terry Reedy -
Tres Seaver