[Python-ideas] Interrogate alternate namespace keyword and concept

ilya ilya.nikokoshev at gmail.com
Fri Aug 14 22:15:19 CEST 2009


Well,

> foo = 32
> interrogate(test_ns):
>   print .foo
>   print foo
>

can be changed to

foo = 32
_ = test_ns
print _.foo
print foo

which actually has less symbols and doesn't have any ambiguity as for
the meaning of the new statement!

> But don't find all that paletable.  My thoughts on this would be to cover
> the parent local namespace, and even globals with your object, the object

If a suggestion is to resolve names into several dictionaries, I don't
think this is practical in any way! As the source you cited correctly
explains, there is an irreparable problem. Suppose I write

foo = 32
interrogate(test_ns):
   print bar  # test_ns.bar
   print foo  # global foo

Then some time later I add global variable bar somewhere in the module
and the program is mysteriously broken! The same thing happens if you
first consult test_ns.__dict__ -- somebody can always add foo to
test_ns, its parent or *even object class*.

So I don't think there's a good way to define semantics of
'interrogate' without some kind of dot-syntax, which is debated for
Python for quite a long time without success.


On Fri, Aug 14, 2009 at 11:46 PM, Prozacgod<prozacgod at gmail.com> wrote:
> I just read this inside of the C# reasoning, and this pretty much kinda
> says, look its to difficult...
>
> This is a good reason "Another approach is to push a scope and make the
> property hide the local variable, but then there's no way to refer to the
> local without adding some escape syntax."
>
> bascially, they added the dot syntax to acces variables that are intended to
> be directed towards object namespace.  Which I do agree helps with
> disambiguation,
>
> foo = 32
> interrogate(test_ns):
>   print .foo
>   print foo
>
> But don't find all that paletable.  My thoughts on this would be to cover
> the parent local namespace, and even globals with your object, the object
> gets it first everytime, and if it raised an exception, then the normal
> method would be implemented.  If it were important to have a variable that
> was named the same, then access it outide the interrogate block or
> otherwise..  But if you were a developer and working on writing a program,
> knowing you wanted to use interrogate, then wouldn't you be wise to choose
> different variable names?  I think I would.
>
> Also doing this is kinda kludgy feeling to me..
>
> function(args).dict[index][index].a = 21
> function(args).dict[index][index].b = 42
> function(args).dict[index][index].c = 63
>
> write this:
>
> ref = function(args).dict[index][index]
> ref.a = 21
> ref.b = 42
> ref.c = 63
>
> even though it is optimised, and works well, this feels more like the
> programmer adapting to the environment instead of the environment working
> for the programmer.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>



More information about the Python-ideas mailing list