<div class="im">Oh .. good call, you right, this would be difficult to observe, find, and correct<br><br>>foo = 32<br>
>interrogate(test_ns):<br>
</div>>  print bar  # test_ns.bar<br>>  print foo  # global foo<br>
<br>>Then some time later I add global variable bar somewhere in the module<br>>and the program is mysteriously broken! The same thing happens if you<br>>first consult test_ns.__dict__ -- somebody can always add foo to<br>

>test_ns, its parent or *even object class*.<br>
<br>In delphi/pascal they left this up to the developer, so you're supposed to divine that a new property was made on a class, to me that is a reasonable trade-off, I could choose to only use this syntax on code that I'm writing and supporting, or realize something could break - BUT I also understand the mentality of - it shouldn't randomly break ever, which is a reasonable supposition of code you write.<br>

<br>After this discussion I'm wondering why it ever ended up in any language to begin with?  Seems like it opens up to many issues to the developers using the language and the language implementors.<br><br><div class="gmail_quote">

On Fri, Aug 14, 2009 at 3:15 PM, ilya <span dir="ltr"><<a href="mailto:ilya.nikokoshev@gmail.com">ilya.nikokoshev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Well,<br>
<div class="im"><br>
> foo = 32<br>
> interrogate(test_ns):<br>
>   print .foo<br>
>   print foo<br>
><br>
<br>
</div><div class="im">can be changed to<br>
<br>
foo = 32<br>
</div>_ = test_ns<br>
print _.foo<br>
print foo<br>
<div class="im"><br>
which actually has less symbols and doesn't have any ambiguity as for<br>
the meaning of the new statement!<br>
<br>
</div><div class="im">> But don't find all that paletable.  My thoughts on this would be to cover<br>
> the parent local namespace, and even globals with your object, the object<br>
<br>
</div><div class="im">If a suggestion is to resolve names into several dictionaries, I don't<br>
think this is practical in any way! As the source you cited correctly<br>
explains, there is an irreparable problem. Suppose I write<br>
<br>
</div><div class="im">foo = 32<br>
interrogate(test_ns):<br>
</div><div class="im">   print bar  # test_ns.bar<br>
   print foo  # global foo<br>
<br>
Then some time later I add global variable bar somewhere in the module<br>
and the program is mysteriously broken! The same thing happens if you<br>
first consult test_ns.__dict__ -- somebody can always add foo to<br>
test_ns, its parent or *even object class*.<br>
<br>
So I don't think there's a good way to define semantics of<br>
'interrogate' without some kind of dot-syntax, which is debated for<br>
Python for quite a long time without success.<br>
<br>
<br>
On Fri, Aug 14, 2009 at 11:46 PM, Prozacgod<<a href="mailto:prozacgod@gmail.com">prozacgod@gmail.com</a>> wrote:<br>
</div><div><div></div><div class="h5">> I just read this inside of the C# reasoning, and this pretty much kinda<br>
> says, look its to difficult...<br>
><br>
> This is a good reason "Another approach is to push a scope and make the<br>
> property hide the local variable, but then there's no way to refer to the<br>
> local without adding some escape syntax."<br>
><br>
> bascially, they added the dot syntax to acces variables that are intended to<br>
> be directed towards object namespace.  Which I do agree helps with<br>
> disambiguation,<br>
><br>
> foo = 32<br>
> interrogate(test_ns):<br>
>   print .foo<br>
>   print foo<br>
><br>
> But don't find all that paletable.  My thoughts on this would be to cover<br>
> the parent local namespace, and even globals with your object, the object<br>
> gets it first everytime, and if it raised an exception, then the normal<br>
> method would be implemented.  If it were important to have a variable that<br>
> was named the same, then access it outide the interrogate block or<br>
> otherwise..  But if you were a developer and working on writing a program,<br>
> knowing you wanted to use interrogate, then wouldn't you be wise to choose<br>
> different variable names?  I think I would.<br>
><br>
> Also doing this is kinda kludgy feeling to me..<br>
><br>
> function(args).dict[index][index].a = 21<br>
> function(args).dict[index][index].b = 42<br>
> function(args).dict[index][index].c = 63<br>
><br>
> write this:<br>
><br>
> ref = function(args).dict[index][index]<br>
> ref.a = 21<br>
> ref.b = 42<br>
> ref.c = 63<br>
><br>
> even though it is optimised, and works well, this feels more like the<br>
> programmer adapting to the environment instead of the environment working<br>
> for the programmer.<br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-Prozacgod<br><br>"Prozac may heal the mind, but friends can mend the soul"<br>