A Frame-space syntax ? - Re: global, globals(), _global ?

[Alex Martelli]

robert <no-spam at no-spam-no-spam.com> wrote:
   ...
> > Not sure I entirely understand what you're proposing, but locals access
> > must remain compile-time-optimized for crucial practical reasons, so
> > "writing to locals()" just will not work right.
> 
> Why will a definite write to _certain_ top local dict consume any extra
> time?

Writing to a dict intrinsically takes longer than writing to a fixed
offset into a vector.  locals(), as a dict, is in fact built as a shim
on top of the fixed vector where a function's locals are kept. We're
talking of a difference in timing of over a factor of two, over a
microsecond per local-variable access on my laptop -- the average
function does so much locals-accessing that I would expect it to slow
down proportionally, by a factor of two or so, if locals were actually
kept in a dictionary rather than in a vector.

Try it out by running the same code as a module's main body versus
running it as a function -- see how much the latter approach speeds
things up. Indeed, "put the code inside a function" is the first
optimization tip to give to any newbie, exactly because a module's
top-level code actually does read/write a dict for each variable access,
while a function's body code does not.

> The target can still be directed fix at compile time. See below.

None of the examples you give below exemplifies "writing to
locals() could be defined as writing to the top-frame-locals" as you had
proposed in the snippet I was responding to.


> > Ugly enough that Guido has never wanted to entertain such possibilities
> 
> Maybe a syntax could be applied which is already known for float 
> litterals and which seems to be intuitive and compatible to me:
> 
> a=1
> .a=1             # same

Just about exactly this syntax was recently discussed on python-dev and
Guido (and many others) shot it down in no time. Please do take the tiny
trouble to research the python-dev archives, as I already suggested,
before proposing something that's so recently been roundly rejected.

> As far as I see this would not slow down the interpreter at run time 
> (except maybe for the new "..b=" intermediate local write's)

Each local access that goes to a dict instead of a fixed vector will
intrinsically and inevitably slow down by 2-3 times. And the fact that
sometimes accessing a local c is the same as accessing .c, and sometimes
it isn't, is something I'm *EXTREMELY* happy to not have to teach,
explain, and justify.


Alex