global, globals(), _global ?

[robert]

Alex Martelli wrote:

> robert <no-spam at no-spam-no-spam.com> wrote:
> 
> 
>>Using global variables in Python often raises chaos. Other languages use
>>a clear prefix for globals.
> 
> Ruby does ($ means global), but, what other languages?  Perl, C, C++,
> Java (taking a class's statics as Java's equivalent of other languages'
> globals), etc, etc, all use the same lexical form for identifiers
> whether local or global, disambiguating in other ways, not by "a clear
> prefix" ('my' in Perl to declare locals, sort of like 'global' in Python
> to declare globals, just with the default the other way 'round, etc).
> Can you please explain what you mean here?

I though first of Ruby.

Good C++ code uses  m_ , g_  for members, globals, ...  e.g. the 
Microsoft MFC code ( you have to declare the vars anyway - and it is 
compiler checked unlike in dict-languages ), :: for global namespace.

In Scheme like:

           (global-set! SYMBOL X)
           (set! (global-ref SYMBOL) X)

Python has taken the 'global' statement from TCL,PHP,.. which are a 
namespace languages. That was unnecessary - as Python modules are 
already real objects.


> Anyway, I'd LOVE expunging the hated 'global' in favour of an explicit
> namespace (and another one for "free variables in containing functions"
> for closures), but while this gets often proposed in python-dev, Guido
> is apparently never going to approve such a change (even in Py3k where
> backwards compatibility could be broken), so I've given up on it.

If the _global virtual remains something like an object (which I'd 
recommend), there is compatibility. if 'global' has to be dropped? or 
just be moved to the end of the docs...

Opening the local namespace is difficult, because the global scope is 
the default; only x=   declares the local.

I think its good to leave the default global binding (that is probably 
whats Guido doesn't want to give up for good reason)

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.

---

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.

Robert