Mark Lutz wrote:

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?

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

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.

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.

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.

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/

Christian Tismer wrote:

...

Mark Lutz wrote: ...

...

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.

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

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.

[GC Example, __dict__ example]

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]

...

...

Mark Lutz wrote: [standard, to avoid confusion] ... 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).

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