Repository navigation
Better specify number of nested scopes #70393
Description
Activity
RoscoeRHiggins commented on Jan 26, 2016
In chapter 9. Classes of the Python3.5 documentation it says:
"At any time during execution, there are at least three nested scopes whose namespaces are directly accessible:",
followed by a list containing 4 items.
Further down a middle scope is mentioned (although mentioned by name). This was confusing for a while.
https://docs.python.org/3/tutorial/classes.html for the docs that Roscoe is talking about.
So the sentence is technically correct, it just takes careful reading to grasp what's being said. There are "at least three nested scopes", but there can be *up to* four scopes. Since "the scopes of any enclosing functions" is not necessarily true for all code scopes, you end up with at least three, but possibly four scopes.
Obviously the wording could be clearer, so if you want to sign the CLA, Roscoe, and propose a rewording that would be appreciated!
Better at least two, if I'm not wrong: the innermost scope may be the module's scope. So there is always at least the module scope and the built‑ins scope, at least two up to four.
(if I have not overlooked something)
It depends on how you want to view things as to whether you can claim there are two or three scopes for module-level code. While it's true that the local scope operates just like global scope, to Python it's more like local == global rather than the local scope simply doesn't exist (hence why locals() never throws an exception saying the scope doesn't exist but instead is the same as globals()).
The "three scope" phrasing also predates nested scopes from back when Python had its LGB scoping rules: Local-Global-Builtin. Back then we just said Python had three scopes and left it at that since it was basically always true and didn't confuse anyone.
At this point I'm fine with just removing the number from the sentence and saying something like "At any time during execution, there are various nested scopes whose namespaces are directly accessible:".
Would 'three or more' be any clearer than 'at least three'? They mean the same, but the first seems better to me in this context.
The real problem with this section are a) the use of Guido's first person 'I' and b) statements that were not changed when nested scope were added, but should have been.
"If a name is declared global, then all references and assignments go directly to the middle scope containing the module’s global names."
The global scope is no longer the middle scope. Roscoe pointed at this. With that removed, the sentence says that if a name is declared global, assignments go to global scope. This would be more meaningful if prefixed by a revised version of the following, which is several paragraphs down.
"A special quirk of Python is that – if no global statement is in effect – assignments to names always go into the innermost scope."
The special quirk part should go; 'global' would now have to be 'global or nonlocal', but I now think the following, preceeding the revised 'global' sentence above, would be better.
"By default, assignments to names always go into the innermost, local, namespace."
In other words, I think the sentence Roscoe flagged is the least of the problems with this section.
Assigning to @Mariatta for the sprints.
15 remaining items
Well, then "what name is in which namespace" is relative to which function we're considering. In my example above, imagine aa has x declared, bb has y, and cc has z. Then y and z are in the same namespace when we look from the perspective of aa, but they are not in the same namespace from the perspective of bb. Even worse, cc sees z but doesn't see y. How can they be in the same namespace then?
I always thought about namespaces as mappings from names to objects, independent of perspective. Whether two names are in the same namespace, should be a question with an objective answer.
Since you ask, here is a extended summary of namespaces. There is one built-in namespace. There is one global namespace for each module, which is also the local namespace for top level code in that module. There is one local namespace for each class and function. There is one nonlocal namespace for each nested function. "At any time during execution" (the beginning of the doc sentence targeted by this issue), there are 3 or maybe 4 namespaces accessible with simple undotted names.
Module global and class local namespaces, including nested classes, are accessible from without the object with dotted names. There are rules for class and method code about access to superclass namespaces. Function locals are not necessarily accessible with standard python code, but at least in cpython, local names can be accessed via code objects. Default parameter values and current nonlocal values, when set, can be accessed via function objects. Dotted names are discussed elsewhere in the tutorial, while function and code object introspection is out of scope there. (And off topic for this issue ;-).
Besides the sentence now revised, the initial post referenced confusion with 'middle scope' in "If a name is declared global, then all references and assignments go directly to the middle scope containing the module's global names."
This has not been directly discussed that I could find, but it seems inappropriate both at toplevel, where globals = locals, and in nested functions, where nonlocals are also 'middle'. Maybe replace "the middle scope containing the module's global names" with "the module's global namespace". The rest of this paragraph and the next could be reviewed.
There is one local namespace for each class and function. There is one
nonlocal namespace for each nested function.
In the first sentence, replace "class" with "class statement" and "function" with "function call". The second sentence could use "nested-function call", but maybe rewrite it as, "There is one nonlocal namespace when a nested function is called."
#98839 for clarifying "middle" scope
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: