-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 29, 2009, at 6:31 AM, A.M. Kuchling wrote:
If we intend for 3.0 to be a 'beta release', or to weaken the 'no features in micro releases' rule, then fine; but we have to be *really clear about it*. Are we? (The 3.0 release page calls it production-ready.)
I think it sets bad precedence to downgrade our confidence in the release. Again, my position is that it's better to stick to the same development processes we've always used, fix the most egregious problems in 3.0.1 with no API changes, but spend most of our energy on a 3.1 release in 6 months. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYHga3EjvBPtnXfVAQLQxQP+Ipu3J0Ogvj0kW4txTgu8SJ4Hr6q7ll7i uyASnNQdB0WV3My1VsymMb5VlIWJtuvwY4DxYR1fqLHOQY6CloFqmmIkeMpZKt/K qXqNI1OvyLfoqg6QqXI+A4UFnUwlv7bSFHqZUu8wVn4De/kQqVfFUgjxBCoNe0lj 0au4xGdjjYo= =qOne -----END PGP SIGNATURE-----
On Jan 29, 2009, at 6:31 AM, A.M. Kuchling wrote:
If we intend for 3.0 to be a 'beta release', or to weaken the 'no features in micro releases' rule, then fine; but we have to be *really clear about it*. Are we? (The 3.0 release page calls it production-ready.)
On Thu, Jan 29, 2009 at 8:59 AM, Barry Warsaw
I think it sets bad precedence to downgrade our confidence in the release. Again, my position is that it's better to stick to the same development processes we've always used, fix the most egregious problems in 3.0.1 with no API changes, but spend most of our energy on a 3.1 release in 6 months.
I'd like to find a middle ground. We can all agree that the users of 3.0 are a small minority compared to the 2.x users. Therefore I think we can bend the rules more than we have done for the recent 2.x releases. Those rules weren't always there (anyone remember the addition of bool, True and False to 2.2.1?). The rules were introduced for the benefit of our most conservative users -- people who introduce Python in an enterprise and don't want to find that they are forced to upgrade in six months. Frankly, I don't really believe the users for whom those rules were created are using 3.0 yet. Instead, I expect there to be two types of users: people in the educational business who don't have a lot of bridges to burn and are eager to use the new features; and developers of serious Python software (e.g. Twisted) who are trying to figure out how to port their code to 3.0. The first group isn't affected by the changes we're considering here (e.g. removing cmp or some obscure functions from the operator module). The latter group *may* be affected, simply because they may have some pre-3.0 code using old features that (by accident) still works under 3.0. On the one hand I understand that those folks want a stable target. On the other hand I think they would prefer to find out sooner rather than later they're using stuff they shouldn't be using any more. It's a delicate balance for sure, and I certainly don't want to open the floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I really don't believe that the strictest interpretation of "no new features" will benefit us for 3.0.1. Perhaps we should decide when to go back to a more strict interpretation of the rules based on the uptake of Python 3 compared to Python 2. I don't believe that we risk influencing that uptake by bending the rules; the uptake will depend on the availability of ported 3rd party packages and some performance gains. (I don't know enough about the C reimplementation of io.py to tell whether it could be folded into 3.0 or will have to wait for 3.1.) Finally, to those who claim that 2.6 is a mess because multiprocessing wasn't perfectly stable at introduction: that's never been the standard we've used for totally *new* features. It's always been okay to add slightly immature features at a major release, as long as (a) they don't break anything else, and (b) we can fix things in the next release while maintaining backward compatibility. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote: [...]
Finally, to those who claim that 2.6 is a mess because multiprocessing wasn't perfectly stable at introduction: that's never been the standard we've used for totally *new* features. It's always been okay to add slightly immature features at a major release, as long as (a) they don't break anything else, and (b) we can fix things in the next release while maintaining backward compatibility.
There's a large distance between saying its introduction was ill-advised and that 2.6 is a mess. I certainly never intimated such a thing (I said it was "a rushed release"). Did anyone? Of course we can fix it. Of course 2.6 is great. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
On Thu, Jan 29, 2009 at 10:57 AM, Steve Holden
Guido van Rossum wrote: [...]
Finally, to those who claim that 2.6 is a mess because multiprocessing wasn't perfectly stable at introduction: that's never been the standard we've used for totally *new* features. It's always been okay to add slightly immature features at a major release, as long as (a) they don't break anything else, and (b) we can fix things in the next release while maintaining backward compatibility.
There's a large distance between saying its introduction was ill-advised and that 2.6 is a mess. I certainly never intimated such a thing (I said it was "a rushed release"). Did anyone?
I don't think that 2.6 as a whole counts as a rushed release, despite the inclusion of multiprocessing. And I don't think it was ill-advised either.
Of course we can fix it. Of course 2.6 is great.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
From: "Guido van Rossum"
On the one hand I understand that those folks want a stable target. On the other hand I think they would prefer to find out sooner rather than later they're using stuff they shouldn't be using any more. It's a delicate balance for sure, and I certainly don't want to open the floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I really don't believe that the strictest interpretation of "no new features" will benefit us for 3.0.1. Perhaps we should decide when to go back to a more strict interpretation of the rules based on the uptake of Python 3 compared to Python 2.
That seems like a smart choice to me. Make the fixups as early as possible, before there has been significant uptake. Am reminded of a cautionary tale from The Art of Unix Programming http://www.faqs.org/docs/artu/ch15s04.html#id2986550 : """ No discussion of make(1) would be complete without an acknowledgement that it includes one of the worst design botches in the history of Unix. The use of tab characters as a required leader for command lines associated with a production means that the interpretation of a makefile can change drastically on the basis of invisible differences in whitespace. "Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history." -- Stuart Feldman """ Raymond
Raymond Hettinger wrote:
From: "Guido van Rossum"
On the one hand I understand that those folks want a stable target. On the other hand I think they would prefer to find out sooner rather than later they're using stuff they shouldn't be using any more. It's a delicate balance for sure, and I certainly don't want to open the floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I really don't believe that the strictest interpretation of "no new features" will benefit us for 3.0.1. Perhaps we should decide when to go back to a more strict interpretation of the rules based on the uptake of Python 3 compared to Python 2.
That seems like a smart choice to me. Make the fixups as early as possible, before there has been significant uptake.
Am reminded of a cautionary tale from The Art of Unix Programming http://www.faqs.org/docs/artu/ch15s04.html#id2986550 :
"""
No discussion of make(1) would be complete without an acknowledgement that it includes one of the worst design botches in the history of Unix. The use of tab characters as a required leader for command lines associated with a production means that the interpretation of a makefile can change drastically on the basis of invisible differences in whitespace.
"Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history." -- Stuart Feldman
"""
I suspect that the use of significant whitespace is too deeply ingrained in Python for us to change it now - even in Python 3. ;-) Michael
Raymond
_______________________________________________ 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 29, 2009, at 1:13 PM, Guido van Rossum wrote:
I'd like to find a middle ground. We can all agree that the users of 3.0 are a small minority compared to the 2.x users. Therefore I think we can bend the rules more than we have done for the recent 2.x releases. Those rules weren't always there (anyone remember the addition of bool, True and False to 2.2.1?). The rules were introduced for the benefit of our most conservative users -- people who introduce Python in an enterprise and don't want to find that they are forced to upgrade in six months.
Removing stuff that should have been removed is fine, and I'm even okay with bending the "should have been" definition.
Frankly, I don't really believe the users for whom those rules were created are using 3.0 yet. Instead, I expect there to be two types of users: people in the educational business who don't have a lot of bridges to burn and are eager to use the new features; and developers of serious Python software (e.g. Twisted) who are trying to figure out how to port their code to 3.0. The first group isn't affected by the changes we're considering here (e.g. removing cmp or some obscure functions from the operator module). The latter group *may* be affected, simply because they may have some pre-3.0 code using old features that (by accident) still works under 3.0.
I mostly agree. I'm also concerned about downstream consumers that may be distributing 3.0 and will have a different schedule for doing their upgrades. What I really want to avoid is people having to do stuff like the ugliness to work around the 2.2.1 additions: try: True except NameError: True = 1 False = 0 Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYMZ5nEjvBPtnXfVAQJZyAP/dAbxc37a3HPfZ6SYH29OxfsyWeist6yk 0jli2WVDiLnc9iYmLky3Bj/B7aijZpq2X2/UOS/F6akOYJhLKfjYckiXzcjBmBIK Ypy3uGrw1wRFxz4ZrJGGzBjxvzSkbYj8ijkGsPqm95FDalq2YOXtrRbOft861dyy 4i2APtZ40AA= =s7U3 -----END PGP SIGNATURE-----
Guido van Rossum schrieb:
Frankly, I don't really believe the users for whom those rules were created are using 3.0 yet. Instead, I expect there to be two types of users: people in the educational business who don't have a lot of bridges to burn and are eager to use the new features; and developers of serious Python software (e.g. Twisted) who are trying to figure out how to port their code to 3.0. The first group isn't affected by the changes we're considering here (e.g. removing cmp or some obscure functions from the operator module). The latter group *may* be affected, simply because they may have some pre-3.0 code using old features that (by accident) still works under 3.0.
On the one hand I understand that those folks want a stable target. On the other hand I think they would prefer to find out sooner rather than later they're using stuff they shouldn't be using any more. It's a delicate balance for sure, and I certainly don't want to open the floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I really don't believe that the strictest interpretation of "no new features" will benefit us for 3.0.1. Perhaps we should decide when to go back to a more strict interpretation of the rules based on the uptake of Python 3 compared to Python 2.
+1. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
I think it sets bad precedence to downgrade our confidence in the release. Again, my position is that it's better to stick to the same development processes we've always used, fix the most egregious problems in 3.0.1 with no API changes, but spend most of our energy on a 3.1 release in 6 months.
+1 Martin
participants (7)
-
"Martin v. Löwis" -
Barry Warsaw -
Georg Brandl -
Guido van Rossum -
Michael Foord -
Raymond Hettinger -
Steve Holden