[Python-3000] Python 3000 Status Update (Long!)

[Alex Martelli]

On 6/22/07, Jean-Paul Calderone <exarkun at divmod.com> wrote:
   ...
> This is more reasonable, but it's still a new rule (and I personally
> find rules which include undefined behavior to be distasteful -- but
> your suggestion could be modified so that the name change is never
> respected to achieve roughly the same consequence).  And it's not even

That would put a potentially heavy burden on Python compilers that may
not be interested in producing speedy code but in compiling faster.
Specifically asserting that some _weird_ behavior is undefined in
order to allow the writing of compilers without excessive burden is
quite sensible to me, in general.  For example, what happens to
'import foo' statements if some foo.py appears, disappears, and/or
changes somewhere on sys.path during the program run IS "de facto"
undefined (for filesystems with sufficiently flaky behavior, such as
remote ones:-) -- I'd like that to be stated outright in the docs, to
allow a sensible and compliant import system to perform some caching
(e.g. ensuring os.listdir is called no more than once per directory in
sys.path) without lingering feelings of guilt or trickiness.

> a rule imposed for a good reason (good reasons are reasons of semantic
> simplicity, consistency, etc), it's just imposed to make it easier to
> optimize the runtime.  If the common case is to read a name repeatedly
> and not care about writes to the name, then leave the language alone and
> just optimize reading of names.  For example, have the runtime set up
> observers for the names used in a function and require any write to a
> name to notify those observers.  Now lookups are fast, the semantics
> are unchanged, and there are no new rules.

However, this would not afford the same level of optimization (e.g.
special opcodes for very lightweight builtins such as len), and if it
involved making all dicts richer to support 'observers on key rebinds'
might possibly slow dicts by enough to more than counteract the
benefits (of course it might be possible to get away with replacing
builtin and modules' dicts with instances of an "observabledict"
subclass -- possibly worthwhile, but a HUGE workload to undertake in
order to let some weirdo reassign 'len' in builtins at random times).
Practicality beats purity.


Alex