On Fri, 22 Jun 2007 14:06:07 -0700, Alex Martelli <[EMAIL PROTECTED]> wrote: >On 6/22/07, Jean-Paul Calderone <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
