logstx at bellatlantic.net
Mon Mar 25 01:32:40 CET 2002
> This is a known, zero priority problem. See my recent posts on the
> develop-test-debug cycle.
It's a feature, not a bug ;)
One of the big bullet items for python is that it operates in a dynamic
environment. The programmer can modify the environment at runtime. In a
dynamic environment, you don't want to trust the system to decide what
existing objects should be killed (other than gc) or what existing objects
do or don't need to be fixed. It's up to the programmer to explicitly do
this if he/she wants to. An even more unforgivable sin than not having the
system "fix" broken objects/dependencies/etc is to allow the system to break
currently functioning and running objects. It's very difficult (probably
impossible) to write a general-purpose, "if-it-ain't-broke-don't-fix-it"
algorithm. Given this, it makes sense that the only way to ensure that
you've returned to the initial state of the environment is to kill it and
create a new one.
Now I'm not saying you need to agree with this (you obviously don't), but it
is a genuine philosophical decision on how things should operate, as opposed
to an oversight or bug needing to be corrected. There are probably lisp or
smalltalk programmers at the other end of the spectrum who think that an
image of the enviroment should be saved automatically when you shut down the
interpreter. Then when you open it up again you're NOT in any sort of
'initial state', but right where you left off, bugs and all.
There are also people who get very upset that 1) there is no mechanism for
static typing in Python, 2) there are no plans to add it, and 3) (even worst
of all!) noone cares. This is another philosophical decision and not an
And, of course, with all philosophical decisions, it's really hard to prove
who's right and who's wrong. [Except mob rule, and it looks like the mob has
More information about the Python-list