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

[Jean-Paul Calderone]

On Fri, 22 Jun 2007 14:28:12 -0700, Alex Martelli <aleaxit at gmail.com> wrote:
>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.

Could be.  I don't find many of my programs to be bottlenecked on
compilation time or import time, so these optimizations look like
pure lose to me.

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

I also don't find much of my code bottlenecked on local name lookup.
Function call and attribute lookup overhead is a much bigger killer,
but I can still write apps where the Python VM isn't the bottleneck
without really trying, and when something is slow, giving attention
to the miniscule fraction of my overall codebase which causes the
problem is itself not much of a problem.

Is it neat when CPython gets faster overall?  Sure.  Is it worth
complications to the language for what is ultimately a tiny
speedup?  Not on my balance sheet.

Jean-Paul