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

[Jean-Paul Calderone]

On Fri, 22 Jun 2007 14:06:07 -0700, Alex Martelli <aleaxit at gmail.com> wrote:
>On 6/22/07, Jean-Paul Calderone <exarkun at divmod.com> wrote:
>   ...
>> >> Calling abs() could change locals()['abs'], in which case a different
>> >> function would be called the next time through.  You lookup 'abs' each
>> >> time just in case it's changed.
>> >>
>> >
>> >I can't think of a reason to allow that outside of something like an
>> >obfuscated Python code contest. I'm sure there exists someone who thinks
>> >differently...
>>
>>The perfectly good reason to allow it is that it is a completely
>>predictable, unsurprising consequence of how the Python language
>>is defined.
>>
>>Making a special case for the way names are looked up in a genexp
>>means making it harder to learn Python and to understand programs
>>written in Python.
>
>Absolutely: it should NOT be about specialcasing genexp.  Rather, it
>would be some new rule such as:
>"""
>If a built-in name that is used within the body of a function F is
>rebound or unbound (in the builtins' module or in F's own module),
>after 'def F' executes and builds a function object F', and before any
>call to F' has finished executing, the resulting effect is undefined.
>"""
>This gives a future Python compiler a fighting chance to optimize
>builtins' access and use -- quite independently from specialcases such
>as genexps.  (Limiting the optimization to functions is, I believe,
>quite fine, because similar limitations apply to optimization of
>local-variable access; IOW, people who care about the speed of some
>piece of code had better make that code part of some function body,
>already:-).
>

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

No, I'm not volunteering to implement this, but if someone else is
interested in spending time speeding up CPython, then this is worth
trying first (and it is worth trying to think of other ideas that
don't complicate the language).

Jean-Paul