Talin wrote:
To put it another way - I am an advocate of applying Claude Shannon's theory of information to language design. The highest level of compression should be used for expressions that occur the most frequently.
I believe the proposal in question would cause no net worsening in this information content, and may actually improve it slightly, due to allowing a few things to be written in a shorter and clearer way, while allowing the vast majority of existing things to be written in exactly the same way.
I'd say that the more common case is where you want global to really mean global - that is, you want to be able to write to some module-level variable, regardless of how deeply nested your function scope is.
It would still mean that, except in the (expected to be *extremely* rare) case where you happened to have a variable with the same name assigned in some intermediate scope. Such cases would be easily fixed by renaming the intermediate variable -- using a name of shorter or equal length, if you like, to keep the information content up. :-)
So changing the behavior of 'global' in this case would be both confusing (since it no longer means 'global'),
An alternative would be to change the keyword as well, to something like 'outer', which would better match its semantics. But if that were done, I would argue for the *removal* of the existing 'global' keyword, which would then be almost completely redundant. This would break large amounts of existing code, however, and it's highly dubious whether that would be worth the small increase in pendantic accuracy, even in Py3k. We're not supposed to be *gratuitously* breaking things in Py3k, after all.
(This assumes that I haven't completely understood the meaning of the phrase 'not local' - I assumed that it means 'not defined in this scope')
Yes, the new meaning would be "in the next outermost scope where there is an assignment to this name, or the module scope if you get that far".
Python isn't Scheme, and the scoping rules of Python are IMHO more oriented towards practicality and common sense than theoretical purity.
Yes, but I find it hard to regard being *forbidden* from assigning to intermediate scopes as something driven by practical need rather than just being a historical accident. Back when there were strictly two scopes, many people argued themselves blue in the face that this was actually a *good* thing, even if you didn't realise it, and that Python was doing you a favour by enforcing it. Eventually a measure of sanity prevailed, and we got something a lot more like traditional lexical scoping. But one remnant of the old system remained, like a vestigial organ -- the 'global' statement that reaches all the way out to the module scope, regardless of what exists in between. To someone used to lexical scoping in almost any other language that has it, this is a *very* strange and unintuitive thing. Looking back, I think the meaning of 'global' should have been redefined right then at the same time. That would have been the logical and consistent thing to do, and in my opinion would have resulted in a scoping model that was simpler, more useful and no less practical. The most theoretically pure thing would have been to change it to 'outer' at the same time, but that would have broken too much code, and would therefore not have been practical. See, I'm not immune to practicality arguments. :-)
One idea would be to introduce the keyword 'local' which would have the effect of capturing any 'global' statements in any enclosing scope.
That seems unnecessary to me. Or at least not necessary enough to be worth the extra complexity in the scoping model. -- Greg