<div dir="ltr">(posting to the list)<br><br><div>Your description of the problem that this new syntax will fix is based on two design flaws:<br>
<br>
<div>Sorry, but I think you're missing the point... People write bad code and other people read it.<br>This is just an example and there are many other use cases.<br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><div>
<br></div>
As Python exists today, this would be a big change for very little
benefit. global is a keyword, not an object, so the language would need
to allow *some* keywords to be used as if they were objects, but not all
keywords:<br>
<br></blockquote></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Even though here global looks like it is an object, it isn't, since this will cause a SyntaxError:<br>
<br>
y = global # global what?</blockquote></div><div> <br>Well, I didn't proposed them to become objects... There's nothing wrong with some keywords behaving <b>partially</b> like objects.<br></div><div class="im"><div>
<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Of course, global must remain a keyword, for backwards compatibility with code writing things the old way.<br>
<br></blockquote></div><div>Yes. This is what I said<br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
However, I can see some merit in your suggestion, for Python 4000 when
backwards compatibility is no longer an issue. Get rid of the global and
nonlocal declarations, and instead introduce two, or possibly three,
reserved names, similar to None:<br>
<br>
globals<br>
nonlocals<br>
builtins<br>
<br></blockquote><div><br></div></div><div>"builtins" is already a module, so it works already. The other two doesn't need to break compatibility<br><br> <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
each of which is a true object. Now globals.x is equivalent to
globals()['x'], and there is no need for a globals() function or a
global keyword.<br>
<br></blockquote></div><div>If they do become objects, thats true. But the "nonlocal" case is a little more difficult than the "globals" <br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You can't, and you shouldn't need to. How hard is it for you to use a
different name for the global and the local? There are billions of
possible names to choose from, why use the same name for both? Again,
your proposal encourages poorly written code. Good language features
should encourage good code, not bad code. It's actually a good thing
that using global variables is slightly inconvenient, as that helps
discourage people from using them.<span><font color="#888888"><br>
<br></font></span></blockquote></div>Imagine you got the job of
writing the inner function. Some crazy person did the other part and you
cannot break compatibility or something... I'm not sayin it is a real
case, just it would be nice to differ those variables</div></div><div class="gmail_extra"><br clear="all"><div>Joćo Bernardo</div>
<br><br><div class="gmail_quote">2013/5/5 Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 05/05/13 03:47, Joćo Bernardo wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
I couldn't find whether this was proposed or not, but seems interesting to<br>
me:<br>
<br>
Whenever there's an assignment inside a big function, we think it is a<br>
local variable, but it could have been defined as global on top and that<br>
can mess things up if not checked.<br>
</blockquote>
<br></div>
Are you suggesting that checking the top of the function for a global declaration is so difficult that Python needs special syntax to fix that?<br>
<br>
Your description of the problem that this new syntax will fix is based on two design flaws:<br>
<br>
* it's a function using global variables;<br>
<br>
* it's a BIG function;<br>
<br>
Both of which are signs that the function should be re-written, not that the language needs a band-aid to fix some of the pain from poor-quality code. A well-designed language should encourage good code. Both global variables and large monolithic functions are signs of potentially bad code.<div class="im">
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, I why not have attribute syntax on "global" and "nonlocal" keywords?<br>
</blockquote></div>
[...]<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
x = 10<br>
def increment():<br>
global.x += 1<br>
</blockquote>
<br>
<br></div>
As Python exists today, this would be a big change for very little benefit. global is a keyword, not an object, so the language would need to allow *some* keywords to be used as if they were objects, but not all keywords:<br>
<br>
y = global.x + 1 # allowed<br>
<br>
y = for.x + 1 # not allowed<br>
<br>
<br>
Even though here global looks like it is an object, it isn't, since this will cause a SyntaxError:<br>
<br>
y = global # global what?<br>
<br>
<br>
Of course, global must remain a keyword, for backwards compatibility with code writing things the old way.<br>
<br>
However, I can see some merit in your suggestion, for Python 4000 when backwards compatibility is no longer an issue. Get rid of the global and nonlocal declarations, and instead introduce two, or possibly three, reserved names, similar to None:<br>
<br>
globals<br>
nonlocals<br>
builtins<br>
<br>
each of which is a true object. Now globals.x is equivalent to globals()['x'], and there is no need for a globals() function or a global keyword.<br>
<br>
Obviously I have not thought this through in any great detail. For instance, there is only a single None object in the entire Python application, but every module will need its own globals object, and every nested function its own nonlocals object. Maybe this idea is only superficially interesting and no good in practice. But we've got plenty of time to think about it.<br>
<br>
<br>
<br>
[...]<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That way you can have both "global.x", "nonlocal.x" and "x" variables<br>
without conflict.<br>
<br>
x = 10<br>
def f(x):<br>
def g():<br>
# how can I set both "x" variables inside here?<br>
</blockquote>
<br></div>
You can't, and you shouldn't need to. How hard is it for you to use a different name for the global and the local? There are billions of possible names to choose from, why use the same name for both? Again, your proposal encourages poorly written code. Good language features should encourage good code, not bad code. It's actually a good thing that using global variables is slightly inconvenient, as that helps discourage people from using them.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
-- <br>
Steven</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/<u></u>mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br></div>