[Python-Dev] Possible optimization for LOAD_FAST ?
ncoghlan at gmail.com
Mon Jan 3 08:28:58 CET 2011
On Mon, Jan 3, 2011 at 3:36 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> I believe this amounts to saying
> 1) Python code executes in three scopes (rather than two): global builtin,
> modular (misleadingly call global), and local. This much is a possible
> viewpoint today.
> 2) A name that is not an assignment target anywhere -- and that matches a
> builtin name -- is treated as a builtin. This is the new part, and it
> amounts to a rule for entire modules that is much like the current rule for
> separating local and global names within a function. The difference from the
> global/local rule would be that unassigned non-builtin names would be left
> to runtime resolution in globals.
> It would seem that this new rule would simplify the lookup of module
> ('global') names since if xxx in not in globals, there is no need to look in
> builtins. This is assuming that following 'len=len' with 'del len' cannot
> 'unmodularize' the name.
> For the rule to work 'retroactively' within a module as it does within
> functions would require a similar preliminary pass. So it could not work
> interactively. Should batch mode main modules work the same as when
> Interactive mode could work as it does at present or with slight
> modification, which would be that builtin names within functions, if not yet
> overriden, also get resolved when the function is compiled.
This could potentially be handled by having the "exec" mode in
compile() assume it can see all the global assignments (and hence
assume builtin names refer to the builtins), while "single" would
assume this was not the case (and hence skip the optimisation). It may
also need an additional parameter to tell the compiler which names are
known to be visible in the current locals and globals (e.g. to allow
exec() to do the right thing)
This kind of issue is the reason Guido pointed out the idea really
needs someone else to pick it up and run with it - not just to figure
out the implementation details, but also to ferret out the full
implications for the language semantics and backwards compatibility.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev