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
--
http://mail.python.org/mailman/listinfo/python-list
