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

[robert]

Alex Martelli wrote:
> robert <no-spam at no-spam-no-spam.com> wrote:
>    ...

>>I think its good to leave the default global binding (that is probably
>>whats Guido doesn't want to give up for good reason)
> 
> 
> Then, on the principle that there should be preferably only one obvious
> way to do something, we'll never have an _global object as you propose
> (even by any other and much better name;-), because it systematically
> produces TWO equally obvious or unobvious way to access globals.

a path to the globals whould maybe not much different from an alternate 
__dict__ or globals() access. and see below ..

>>Yet frames could expose their top-dict anyway as a virtual inspection
>>object (__l/__l_<funcname> or  __f_stack[-2]) . Or at least writing to
>>locals() could be defined as writing to the top-frame-locals. 
>>Sub-Frames could write free there (its a rare & conscious task anyway)
>>and the Frame itself could read either way.
> 
> 
> 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?
The target can still be directed fix at compile time. See below.

>>Another ugly possibilties maybe by enriching variable assignment.
>>
>>Maybe '=' can be enriched like   .= ..= :=  =: ::= =:: xxx-set ... etc.
>>in order to be an expression with result value and to allow to writing
>>to certain namspaces.
> 
> 
> 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
d=5
def f()
     b=1
     .b=1         # same
     print a
     print ..a    # same
     ..a += 1     # compile-time known: its the global!
     def g():
         ..b=2    # f-local b !
         ..c=3    # write a 'free local' into f-locals
         ..d=4
         ...a += 1   # the compiler knows: its global!
     g()
     print b      # local
     print 1 + .c     # ok
     print c      # error!, but thats acceptable
     print d      # global
     print .d     # local!, but thats acceptable


This syntax shows some kind of self-similarity:
* a dot . always references a definite dict/namespace/obj (or a float)
* a free dot . simply references the top local dictionary (or a float)
* more dots step back through the frame stack
* If no dot is there the usual "automatic name space" is assumed

No old code would be broken.

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)

Robert