[Python-Dev] A house upon the sand

Christian Tismer tismer@tismer.com
Sat, 25 Nov 2000 18:25:32 +0200


(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