Replacement for keyword 'global' good idea? (e.g. 'modulescope'or 'module' better?)

[Paolino]

Bengt Richter wrote:

> Nor do we have any correspondence for bare names analogous to
> 
>     setattr(obj, "name", value) <=> obj.name = value
> 
> e.g.,
> 
>     setname(<namespace_selection>, "name", value)

Probably this parallelism is a better approach to what I commented 
before.Thanks for clarity.
> There is nowhere near the kind of control the programmer has over attribute namespace
> use for bare-name use, even though by various means we are able to select from a limited
> set of namespaces. (BTW, if <namespace_selection> were a call to a suitable builtin function
> that could return objects whose attribute namespace were the desired name space, then setname
> could be effected with setattr, e.g.,
> 
>     setattr(get_ns_obj(), "name", value)    # name = value (defaulting to local, same as get_ns_obj(0))
>     setattr(get_ns_obj(1), "name", value)   # name = value (in lexically immediately (1) enclosing scope)
>     setattr(get_ns_obj(-1), "name", value)  # name = value (in global module scope)
> )  
> 
Yes namespaces should be unified in their base behaviour.
> I am thinking that there is a subliminal discussion under a layer of red herrings ;-)
> I refer to the subject of unification/generalizing/orthogonalizing by removing special
> legacy restrictions (or not introducing special restrictions in a new feature).
> 
> E.g., recently decorators were introduced, and part of the discussion (which became explicit ;-)
> was whether to allow the expression following the '@' to be a fully general expression, or
> whether to restrict it to names, dotted names, and function calls. The latter won out.
> 
> Some regard this kind of restriction as paternalistic, and protest that "we are adults here"
> (even though we are not all, and we others not all the time ;-)
> 
Uhmpf, adults==theorists and childrens==experimentals ?
> The BDFL has introduced many new ideas, yet has retained or introduced restrictions on fully
> orthogonal functionality that might otherwise be allowed if e.g. names in certain contexts
> were allowed to be full expressions. It goes the other way too. IIRC the list of bases for
> a class will be allowed to be an empty "()" soon.
> 
> Bottom line, I think Python is eminently usable and very pleasant to use, but I think bare name
> mechanisms could be improved.
> 
A good dose of humility could be good for reingeneering something ,if 
necessary.Python is very usable,and has an almost perfect surface layer.
But this is not enough.It needs to be strong and elegant in the insides 
  to survive.More, isn't the "Namespaces do more of them" a Python Zen Law ?

Thanks again for putting things in a saner and more open way then I did.

Regards Paolino

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it