Hi again Guido, On a totally unrelated topic: has anyone pushed the idea of a Python language standard lately? Things seem to be changing too fast for many developers to keep up, and it seems to me that a formal standard doc might help ease a few fears I've seen out there. Books used to be a sort of de facto standard, but even they aren't reliable anymore; and the manuals aren't useful as a standard if they are open to arbitrary change every few months. Frankly, some people in my classes are very concerned by the rapid pace of Python change, and I think their fear is justified. I get burned a little almost every time a new Python release rolls out too. Most recently, some new book examples that worked in 1.5.2 this summer no longer work under 2.0 this fall; I understand that most changes are improvements (and minor), but this is not a great story to tell. A prime example: the string module, used in almost every Python program ever written by the half-million Python users out there, has suddenly been marked as deprecated. I expect that it won't really go away, but has anyone considered the impact of even the suggestion of its deprecation on Python's acceptance? If using Python requires that programmers invest lots of time tracking the whims of python-dev, then Python will become much less useful, imo. Most developers just don't have the extra time to spare. A formal standard doc could give us at least a baseline Python definition that developers could cling to. Companies need to see a solid and reliable foundation. Unfortunately, I don't have the time or interest in pushing this idea through to fruition myself. Do you have any ideas along these lines? Maybe this task belongs in whatever body eventually takes over ownership. I'm copying this to python-dev in the hopes that it might trigger some sort of discussion. Cheers, --Mark Lutz (http://rmi.net/~lutz)
Mark Lutz wrote:
It is depreciated because string methods provide a better model of extensibility for future versions. string.py simply interfaces to these new methods. It won't go away, but using the methods directly will provide better performance and an overall better experience... this doesn't mean that Python programmers can no longer use string.py, but it should hint them towards using the string methods instead. Next to come are number methods, AFAICT ;-)
The only major incompatbile changes in 2.0 are the .append() et al. changes and the str(1L) change. These have been highlighted in the changes paper.
I don't see how a Python standard would do any good. Standards have version numbers as well and change at about the same rate (e.g. take Unicode 2.0 vs. Unicode 3.0). Besides, who forces anyone to use 2.0 instead of 1.5.x which has been around for many years now ? Sorry, but I sense bureaucracy kreeping into the house... -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
(Marc, your clock is wrong by 1 hour :) "M.-A. Lemburg" wrote:
Mark Lutz wrote:
...
Saying things explicitly is Mark's point, IMHO. I don't see the danger of bureaucracy so much. Instead, setting a standard is a sign of maturity for a language. Python as it is, and in former versions, was a per-se standard, set by the implementation. The Python documentation explains how things work, but this is a description of the current implementation, not setting possible ranges, like a standard. A standard would allow anybody to write a Python implementation which conforms to it, without knowing all the details of the given implementation. He would not have to guess (or ask Guido) what design decisions are final and considered a part of the language, or just by chance, ease of implementation or whatever reason might have let to it. There are many issues where we know how it works in one implementation and the other, but it is undefined which behavior is intended, by chance, enforced or forbidden. Example: Python 2.0 has now a garbage collector. Not so long ago, a garbage collector seemed out of reach, and before Guido sketched a GC by himself, I even had the impression that a gc was out of question. (should have borrowed the time machine :) JPython had garbage collection in the first place, inherited from Java. So, with Python 1.5.2, 2.0, and JPython, we get three different implementations, and three different lifetimes of objects. It would be helpful if a Python standard would define how an implementation should do this: Do objects have to be destructed at all, or which objects have to, or is it completely up to the implementor to decide? Even if so, then this would be stated, and people who write scripts compliant to Python standard 2.0 would know that they can never rely on object destruction, for instance. Other Example: There are certain design decisions in the object layout, which are exposed to the user, like __dict__ for many objects. It is not clear if this is a language feature or an implementation detail. The current user practice enforces us to support __dict__, I think, although very different decision would be drawn if someone was designing a true compiler for Python. Does it have to exist, and if so, does it have to be a dictionary? Statements like "it happens to be a dict, but anything supported by getattr() would do, but it must be there" would be an example statement, most helpful for alternative implementations, which still fulfill the standard. better-explicit-than-implicit - ly y'rs - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com
Christian Tismer wrote:
Ok. Maybe I misunderstood Mark... if what he wants is a language definition like e.g. the one for Java and its VM then I agree. This would be a good thing. OTOH, I don't see much of a point in giving the user a feeling of fixed standards when we are constantly talking about ways to break code ;-) (e.g. take the Py3K upgrade path PEP). We could have a language definition for say the 2.0 version series, but the definition would have to be extended for the 3.0 series (possibly even within the 2.0 series). It would gives us a feeling of what "Python" stands for and also simplify the task of writing different Python implementations, but nothing much else... certainly not the warm fuzzy feeling which Mark probably had in mind. I think the overall impression of Python 2.0 being a moving target is a bit overrated: there aren't really all that many changes which affect existing code, so a Python 1.5.2 introduction will still remain mostly valid even when the students use Python 2.0. It is true, that Python 2.0 offers a lot more features than 1.5.2 and that in some contexts (e.g. database interfacing on Windows) these new features have made their way into third party extensions rather fast (e.g. switching from strings to Unicode). The visible core language hasn't changed much though... and this is goodness. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
"M.-A. Lemburg" wrote:
Christian Tismer wrote:
[favorizing a standard]
Whatever other feelings come into play, a standard would be a good thing, IMHO. Aside, the PERL world is thinking into this direction as well. See this rosler article (also interesting concerning Python:) http://www.perl.com/pub/2000/06/rosler.html Since Python is so much cleaner and smaller (still?), this is a chance to be the winder here. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com
"M" == M <mal@lemburg.com> writes:
M> I think the overall impression of Python 2.0 being a moving M> target is a bit overrated: there aren't really all that many M> changes which affect existing code, so a Python 1.5.2 M> introduction will still remain mostly valid even when the M> students use Python 2.0. M> It is true, that Python 2.0 offers a lot more features than M> 1.5.2 and that in some contexts (e.g. database interfacing on M> Windows) these new features have made their way into third M> party extensions rather fast (e.g. switching from strings to M> Unicode). The visible core language hasn't changed much M> though... and this is goodness. I agree completely. What I think freaks people out is all the new features that cropped up in 2.0. People think they have to learn all that new fancy stuff like string methods, list comprehensions, and extended print. For those who watch python-dev from the sidelines, pie-in-the-sky discussions on things like continuations freak people out even more. There's too much brain-blowing new things being added to my nice little language! But it doesn't have to be that way. As others have pointed out, almost all the code that worked for 1.5.2 works for 2.0 and 1.5.2 was released what? 18 months ago? That's a lot of stability these days. I understand that adding new stuff to the language has an impact on slow-update media like books, and that should not be ignored. But people don't have to learn (or be taught) the new features to be just as productive in Python 2.0 as they were in 1.5.2. They can learn the new stuff once they've grasped and are comfortable with the old. 2.0 introduced a lot of new stuff, as much because of social reasons and pressures as for technical benefits. On the flip side, we've had messages in this forum decrying the recent dearth of messages. I suspect that's partly a reaction to all the changes in 2.0, letting the new things settle in. I can't imagine that 2.1 will have nearly as many new features. -Barry
On Sat, Nov 25, 2000 at 05:21:06PM +0100, M.-A. Lemburg wrote:
Mark Lutz wrote:
Unfortunately, the term 'deprecated' suggests to most people, including me, that it will be removed in future versions. I'm with Mark here; marking it deprecated causes a lot of confusions, IMHO. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On the deprecation of the string module: where did this idea come from? I've never seen anything saying that the string module is deprecated. The 2.0 docs say that the three specific functions string.{atoi, atol, atof} are deprecated as of 2.0, but that's it. On the meaning of deprecation: yes, it means they'll go away someday. On gc semantics: Section 3.1 ("Objects, values and types") of the Lang Ref sez: Objects are never explicitly destroyed; however, when they become unreachable they may be garbage-collected. An implementation is allowed to postpone garbage collection or omit it altogether -- it is a matter of implementation quality how garbage collection is implemented, as long as no objects are collected that are still reachable. (Implementation note: the current implementation uses a reference-counting scheme which collects most objects as soon as they become unreachable, but never collects garbage containing circular references.) If Python had a standard, the only thing that would change is that the obsolete parenthetical comment would be removed. On formal standardization: not likely. An ISO/ANSI std takes a minimum of person-decades of work, and Guido would be unable to make the time even to review committee documents. IOW, he won't cooperate, because he can't, and that's that. Propose changes to the Lang Ref instead (for example, Guido's intent was that binary operators of equal precedence be evaluated strictly left to right in the absence of parens, but the Lang Ref never got around to saying so). On the pace of change: by all objective measures, Python change ended the day 2.0 was released <0.9 wink>. the-lang-ref-is-the-only-std-you're-likely-to-get-ly y'rs - tim
Mark Lutz wrote:
I read several different issues into your message: * standards doc * speed of change * deprecations * backwards incompatibilities Standards doc: we have one but it is out of date. I think that it would be great if someone has the bandwidth to improve it but I'm not going to push Guido very hard to do that because there's a lot of more high priority stuff I'd like to see him work on. Speed of change: it wasn't really so radical if you think in terms of how long these suggestions have been "queued". I would not like it if Python kept up the same pace of language additions but I don't think that's going to happen. Deprecation: deprecations are a good thing. They are the only way that Python will ever drop old features. If Python never drops old features then it can only ever grow. If it only ever grows then it will only become more and more difficult to learn. I don't think I have to justify the importance of learnability... Backwards Incompatibilities: I feel strongly that we need to be more conservative about code breakage. Python 2 was not backwards compatible enough. It should have deprecated the code and used warnings instead. Here's my suggested solution for the future: http://python.sourceforge.net/peps/pep-0005.html
Sometimes we make mistakes. Making mistakes is part of learning. String functions should have been methods. We had to correct that mistake. What other mechanism do we have for correcting mistakes other than deprecation? Paul Prescod
Mark Lutz wrote:
It is depreciated because string methods provide a better model of extensibility for future versions. string.py simply interfaces to these new methods. It won't go away, but using the methods directly will provide better performance and an overall better experience... this doesn't mean that Python programmers can no longer use string.py, but it should hint them towards using the string methods instead. Next to come are number methods, AFAICT ;-)
The only major incompatbile changes in 2.0 are the .append() et al. changes and the str(1L) change. These have been highlighted in the changes paper.
I don't see how a Python standard would do any good. Standards have version numbers as well and change at about the same rate (e.g. take Unicode 2.0 vs. Unicode 3.0). Besides, who forces anyone to use 2.0 instead of 1.5.x which has been around for many years now ? Sorry, but I sense bureaucracy kreeping into the house... -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
(Marc, your clock is wrong by 1 hour :) "M.-A. Lemburg" wrote:
Mark Lutz wrote:
...
Saying things explicitly is Mark's point, IMHO. I don't see the danger of bureaucracy so much. Instead, setting a standard is a sign of maturity for a language. Python as it is, and in former versions, was a per-se standard, set by the implementation. The Python documentation explains how things work, but this is a description of the current implementation, not setting possible ranges, like a standard. A standard would allow anybody to write a Python implementation which conforms to it, without knowing all the details of the given implementation. He would not have to guess (or ask Guido) what design decisions are final and considered a part of the language, or just by chance, ease of implementation or whatever reason might have let to it. There are many issues where we know how it works in one implementation and the other, but it is undefined which behavior is intended, by chance, enforced or forbidden. Example: Python 2.0 has now a garbage collector. Not so long ago, a garbage collector seemed out of reach, and before Guido sketched a GC by himself, I even had the impression that a gc was out of question. (should have borrowed the time machine :) JPython had garbage collection in the first place, inherited from Java. So, with Python 1.5.2, 2.0, and JPython, we get three different implementations, and three different lifetimes of objects. It would be helpful if a Python standard would define how an implementation should do this: Do objects have to be destructed at all, or which objects have to, or is it completely up to the implementor to decide? Even if so, then this would be stated, and people who write scripts compliant to Python standard 2.0 would know that they can never rely on object destruction, for instance. Other Example: There are certain design decisions in the object layout, which are exposed to the user, like __dict__ for many objects. It is not clear if this is a language feature or an implementation detail. The current user practice enforces us to support __dict__, I think, although very different decision would be drawn if someone was designing a true compiler for Python. Does it have to exist, and if so, does it have to be a dictionary? Statements like "it happens to be a dict, but anything supported by getattr() would do, but it must be there" would be an example statement, most helpful for alternative implementations, which still fulfill the standard. better-explicit-than-implicit - ly y'rs - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com
Christian Tismer wrote:
Ok. Maybe I misunderstood Mark... if what he wants is a language definition like e.g. the one for Java and its VM then I agree. This would be a good thing. OTOH, I don't see much of a point in giving the user a feeling of fixed standards when we are constantly talking about ways to break code ;-) (e.g. take the Py3K upgrade path PEP). We could have a language definition for say the 2.0 version series, but the definition would have to be extended for the 3.0 series (possibly even within the 2.0 series). It would gives us a feeling of what "Python" stands for and also simplify the task of writing different Python implementations, but nothing much else... certainly not the warm fuzzy feeling which Mark probably had in mind. I think the overall impression of Python 2.0 being a moving target is a bit overrated: there aren't really all that many changes which affect existing code, so a Python 1.5.2 introduction will still remain mostly valid even when the students use Python 2.0. It is true, that Python 2.0 offers a lot more features than 1.5.2 and that in some contexts (e.g. database interfacing on Windows) these new features have made their way into third party extensions rather fast (e.g. switching from strings to Unicode). The visible core language hasn't changed much though... and this is goodness. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
"M.-A. Lemburg" wrote:
Christian Tismer wrote:
[favorizing a standard]
Whatever other feelings come into play, a standard would be a good thing, IMHO. Aside, the PERL world is thinking into this direction as well. See this rosler article (also interesting concerning Python:) http://www.perl.com/pub/2000/06/rosler.html Since Python is so much cleaner and smaller (still?), this is a chance to be the winder here. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com
"M" == M <mal@lemburg.com> writes:
M> I think the overall impression of Python 2.0 being a moving M> target is a bit overrated: there aren't really all that many M> changes which affect existing code, so a Python 1.5.2 M> introduction will still remain mostly valid even when the M> students use Python 2.0. M> It is true, that Python 2.0 offers a lot more features than M> 1.5.2 and that in some contexts (e.g. database interfacing on M> Windows) these new features have made their way into third M> party extensions rather fast (e.g. switching from strings to M> Unicode). The visible core language hasn't changed much M> though... and this is goodness. I agree completely. What I think freaks people out is all the new features that cropped up in 2.0. People think they have to learn all that new fancy stuff like string methods, list comprehensions, and extended print. For those who watch python-dev from the sidelines, pie-in-the-sky discussions on things like continuations freak people out even more. There's too much brain-blowing new things being added to my nice little language! But it doesn't have to be that way. As others have pointed out, almost all the code that worked for 1.5.2 works for 2.0 and 1.5.2 was released what? 18 months ago? That's a lot of stability these days. I understand that adding new stuff to the language has an impact on slow-update media like books, and that should not be ignored. But people don't have to learn (or be taught) the new features to be just as productive in Python 2.0 as they were in 1.5.2. They can learn the new stuff once they've grasped and are comfortable with the old. 2.0 introduced a lot of new stuff, as much because of social reasons and pressures as for technical benefits. On the flip side, we've had messages in this forum decrying the recent dearth of messages. I suspect that's partly a reaction to all the changes in 2.0, letting the new things settle in. I can't imagine that 2.1 will have nearly as many new features. -Barry
On Sat, Nov 25, 2000 at 05:21:06PM +0100, M.-A. Lemburg wrote:
Mark Lutz wrote:
Unfortunately, the term 'deprecated' suggests to most people, including me, that it will be removed in future versions. I'm with Mark here; marking it deprecated causes a lot of confusions, IMHO. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On the deprecation of the string module: where did this idea come from? I've never seen anything saying that the string module is deprecated. The 2.0 docs say that the three specific functions string.{atoi, atol, atof} are deprecated as of 2.0, but that's it. On the meaning of deprecation: yes, it means they'll go away someday. On gc semantics: Section 3.1 ("Objects, values and types") of the Lang Ref sez: Objects are never explicitly destroyed; however, when they become unreachable they may be garbage-collected. An implementation is allowed to postpone garbage collection or omit it altogether -- it is a matter of implementation quality how garbage collection is implemented, as long as no objects are collected that are still reachable. (Implementation note: the current implementation uses a reference-counting scheme which collects most objects as soon as they become unreachable, but never collects garbage containing circular references.) If Python had a standard, the only thing that would change is that the obsolete parenthetical comment would be removed. On formal standardization: not likely. An ISO/ANSI std takes a minimum of person-decades of work, and Guido would be unable to make the time even to review committee documents. IOW, he won't cooperate, because he can't, and that's that. Propose changes to the Lang Ref instead (for example, Guido's intent was that binary operators of equal precedence be evaluated strictly left to right in the absence of parens, but the Lang Ref never got around to saying so). On the pace of change: by all objective measures, Python change ended the day 2.0 was released <0.9 wink>. the-lang-ref-is-the-only-std-you're-likely-to-get-ly y'rs - tim
Mark Lutz wrote:
I read several different issues into your message: * standards doc * speed of change * deprecations * backwards incompatibilities Standards doc: we have one but it is out of date. I think that it would be great if someone has the bandwidth to improve it but I'm not going to push Guido very hard to do that because there's a lot of more high priority stuff I'd like to see him work on. Speed of change: it wasn't really so radical if you think in terms of how long these suggestions have been "queued". I would not like it if Python kept up the same pace of language additions but I don't think that's going to happen. Deprecation: deprecations are a good thing. They are the only way that Python will ever drop old features. If Python never drops old features then it can only ever grow. If it only ever grows then it will only become more and more difficult to learn. I don't think I have to justify the importance of learnability... Backwards Incompatibilities: I feel strongly that we need to be more conservative about code breakage. Python 2 was not backwards compatible enough. It should have deprecated the code and used warnings instead. Here's my suggested solution for the future: http://python.sourceforge.net/peps/pep-0005.html
Sometimes we make mistakes. Making mistakes is part of learning. String functions should have been methods. We had to correct that mistake. What other mechanism do we have for correcting mistakes other than deprecation? Paul Prescod
participants (7)
-
barry＠digicool.com -
Christian Tismer -
M.-A. Lemburg -
Mark Lutz -
Paul Prescod -
Thomas Wouters -
Tim Peters