PEP 266: Optimizing Global Variable/Attribute Access

John Roth johnroth at
Wed Aug 15 20:18:06 CEST 2001

I'm all in favor of performance improvements, but maybe I'm missing
something here?
I just got back onto the NG after an absence of about 2 weeks, so I'm
not up on the prior discussion.

The issue seems to be that to find a variable, you have to search up the
entire static calling chain, using a dictionary lookup at each level until
you find the
object you've named. It seems like the expensive piece is the multi-level
using a dictionary lookup. If this could be speeded up, there wouldn't be
any need
for a "tracking" mechanism, with the attendant complexities.

One way of making this faster would be to change the implementation of the
identifier lookup so that it used an array at all levels. The dictionary
would then
contain identifier/index pairs instead of identifier/object pairs.

Each array entry would then contain a status code, an index and an object
The status is either "here", "deleted" or "forwarded". For "here", the
object reference
is what you want. For 'forwarded', the object points to the next object in
the chain,
and the index specifies which identifier. "Deleted" has the obvious meaning.

There are some obvious complexities, like deleting an identifier requiring a
up the static chain to find out if there is another identifier that has just
become unshielded.

John Roth

"Skip Montanaro" <skip at> wrote in message
news:mailman.997887028.29027.python-list at
>     Skip> Actually, if I do it right, PEPTest2 would work more like
>     Skip>     def PEPTest2():
>     Skip>         m = math.sin
>     Skip>         c = 100000
>     Skip>         while c:
>     Skip>             l = []
>     Skip>             f = l.append
>     Skip>             for i in range(10):
>     Skip>                 f(m(i))
>     Skip>             c -= 1
>     Skip> That is, math.sin would get cached at the earliest point where
>     Skip> is in scope, which would be before the while loop.
> After reading Alex's note on this subject I realized I may have
> misinterpreted what you asked for.  While the PEP266 implementation will
> work about like the manual caching case, note that it will not change
> Python's semantics.  If some other routine modifies the binding for
> during execution of the while loop, the PEPTest2 function will see the
> change, just as it would today if you included math.sin lookups in the
> and unlike the code above which statically binds m to the object referred
> by math.sin at the start of the function.  That's the whole idea of the
> --
> Skip Montanaro (skip at

More information about the Python-list mailing list