(Marc, your clock is wrong by 1 hour :) "M.-A. Lemburg" 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. 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