Alex Martelli wrote: > robert <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list