[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Change by Stefan Krah : -- nosy: -skrah ___ Python tracker ___ ___ Python-bugs-list

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Stefan Krah added the comment: You can access globals, but not through another nested scope where the global name is shadowed. I have to excuse myself from this discussion. It's interesting, but I don't have enough bandwidth. --

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Camion added the comment: I don't think there anything in the definition of "lexical scoping", which forbids to have a way to access globals from some place. Lexical scoping just means that scoping is defined in regards of the source code, by opposition dynamic

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Stefan Krah added the comment: Because in the example in msg308683 true lexical scoping should, when processing g()'s name space, search for the name 'a' in the lexically closest scope f(), find it there and conclude that 'a' cannot be global. --

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Camion added the comment: Stefan, You wrote : « It certainly prevents Python scopes from being called "lexical scopes". » I don't understand why... Could you explain ? -- ___ Python tracker

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Stefan Krah added the comment: > Stefan, your last example is formally speaking OK, if one reads the > "Execution model" literally. The original example is however too +ambiguous, so it is good that it triggers an error. OK yes -- desirable, no. IMO execution models are

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Camion added the comment: What I mean is that we need to clarify (by giving examples ?) what make the scope for the new binding "not be unambiguously decidable", because, for an example : My example is totaly unambiguously decidable for an interpreter. It's for

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Camion added the comment: Ivan, I believe, this sentence : "(the scope in which a new binding should be created cannot be determined unambiguously)" in https://docs.python.org/fr/3/reference/simple_stmts.html#nonlocal, is the one which should be clarified

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Ivan Levkivskyi added the comment: Stefan, your last example is formally speaking OK, if one reads the "Execution model" literally. The original example is however too ambiguous, so it is good that it triggers an error. I think there is a chance to improve the error

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Stefan Krah added the comment: Okay, I have never used something like that. Personally, I'd disallow the global statement in g() if 'a' is local in f(). >>> a = 10 >>> def f(): ... a = 20 ... def g(): ... global a ... print(a) ... g() ... >>>

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Camion added the comment: My interrogation is about the fact that this doesn't seem to have been a collective decision and I'm not even sure it WAS anyone decision : it might as well have been an unintentional consequence of an implementation choice. So, in the

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

R. David Murray added the comment: Hmm. I suppose that could be clarified in the docs. I would find it very counter-intuitive for the grandparent 'a' to be accessible, which is probably why I did not consider that an issue. --

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Camion added the comment: David and Stefan, you're both missing my main point which is the fact that the presence of the global declaration in the parent (g) **blocks the access to the grand parent context**, which would be accessible without this global

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Stefan Krah added the comment: I guess I'd vote for closing this, because the first Google result for "no binding for nonlocal" on Stackoverflow is quite clear. The ideal message would be "'a' cannot be both global and nonlocal", but it would probably complicate the

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

R. David Murray added the comment: When I said "the only thing keeping this issue open" is the message, I should acknowledge that you mentioned clarifying the documentation, but as I pointed out the documentation is already clear: it says nonlocal does not access

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

R. David Murray added the comment: Right, it was indeed "designed that way" in the sense that nolocal was only ever intended to access variables from the surrounding local scope, *not* the global scope. If you put a variable name in the global scope, nonlocal was not

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Stefan Krah added the comment: > Does it makes sense to have the presence of "global a" in g, block all > possibility for h, to access it's grand parent's a ? >From the perspective of ML-style languages with pure lexical scoping, no, it >does not make sense. But Python

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Change by Serhiy Storchaka : -- nosy: +levkivskyi ___ Python tracker ___ ___

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Camion added the comment: Oops, in my previous post please read : "but does it makes sense to have the presence of "global a" in g, block all possibility for h, to access it's grand parent's a ?" instead of "but is makes sense to [...] grand parent's a."

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Camion added the comment: Well, David, I'm convinced this behavior is "logical" and is not some "logic" flaw. My question is more about the fact that it is desirable and was intentionally designed that way,or if on the contrary no one thought it might happen

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

R. David Murray added the comment: What is happening here is that what nonlocal does is give the function containing the nonlocal statement access to the "cell" in the parent function that holds the local variable of that function. When you use a global statement, the

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Camion added the comment: I forgot to mention, that I wonder if the interpreter shouldn't instead, - either consider that since global a is used is g, it should be considered as also local to g from h point of view, - or if h should be able to access f's version

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Change by R. David Murray : -- nosy: +r.david.murray ___ Python tracker ___ ___

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

New submission from Camion : Hello, "PEP 3104 -- Access to Names in Outer Scopes" introduced the keywords "global" and "nonlocal". but didn't make clear (to me) if this behaviour is a bug, an intentional feature, or a design hole which might be considered good