Repository navigation
Limit "global" keyword name conflicts in language spec to those enforced by CPython #58749
Description
| BPO | 14544 |
|---|---|
| Nosy | @rhettinger, @terryjreedy, @ncoghlan, @ezio-melotti, @merwok, @alex |
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:
assignee = None
closed_at = None
created_at = <Date 2012-04-11.04:46:30.833>
labels = ['type-feature']
title = 'Limit "global" keyword name conflicts in language spec to those enforced by CPython'
updated_at = <Date 2015-03-05.10:03:11.434>
user = 'https://github.com/ncoghlan'bugs.python.org fields:
activity = <Date 2015-03-05.10:03:11.434>
actor = 'ezio.melotti'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2012-04-11.04:46:30.833>
creator = 'ncoghlan'
dependencies = []
files = []
hgrepos = []
issue_num = 14544
keywords = []
message_count = 4.0
messages = ['158005', '158006', '158007', '237252']
nosy_count = 8.0
nosy_names = ['rhettinger', 'terry.reedy', 'ncoghlan', 'fossilet', 'ezio.melotti', 'eric.araujo', 'alex', 'cvrebert']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue14544'
versions = ['Python 3.5']
Activity
ncoghlan commentedon Apr 11, 2012
The language spec currently includes the following paragraph [1]:
Names listed in a global statement must not be defined as
formal parameters or in a for loop control target, class
definition, function definition, or import statement.
While the first restriction is real (and enforced by CPython), since formal parameters are explicitly defined as local variables, there's no obvious rationale for the last 4 restrictions (and CPython doesn't enforce any of them).
The proposal is that the paragraph be simplified to:
Names listed in a global statement must not also be defined as
formal function parameters. Attempting to do so raises SyntaxError.
The current (incorrect!) CPython implementation detail note will be removed.
A similar clarification will also be made in the "nonlocal" statement documentation.
[1] http://docs.python.org/dev/reference/simple_stmts.html#the-global-statement
alex commentedon Apr 11, 2012
This shouldn't be a problem for PyPy, in fact I'm almost positive that we implement this already (since Django has a test that uses this "feature"). If/when the spec is changed please make sure there are tests for all these cases so we *know* it works though.
ncoghlan commentedon Apr 11, 2012
Thread link: http://mail.python.org/pipermail/python-ideas/2012-April/014783.html
rhettinger commentedon Mar 5, 2015
+1 for the proposed change. It should add there is also an enforced (and obvious) restriction that the variable not have been declared nonlocal.
gh-58749: Remove incorrect language spec claims about the global stat…
ncoghlan commentedon Nov 12, 2024
Thanks for the PR @bombs-kim! The inaccurate statements in the language spec have now been fixed for 3.14. It looks like the
nonlocalstatement never had the incorrect information added, so it doesn't need any updates.Open items before we close out this issue:
test_nonlocal.pyto mirror thetest_global.pytest cases (behaviour is essentially the same, everything just needs to be pushed down into a nested function so it can use anonlocalstatement referring to a method levelname_for_test_case = Nonelocal name instead of a global one. The equivalent of looking up the name inglobals()for these tests will be to look upf.__closure__[0].cell_contents(assuming the nested functions are just calledf)bombs-kim commentedon Nov 12, 2024
I also agree that we do not need to backport this.
serhiy-storchaka commentedon Nov 12, 2024
Until we backport the documentation changes or change the behavior in 3.12 and 3.13 (which would be disruptive) the bug is not fixed in 3.12 and 3.13.
terryjreedy commentedon Nov 12, 2024
I agree with Serhiy. Discrepancies between doc and implementation are bugs, and can be fixed by changing either, according to which, if either, is considered correct. Either way, bug fixes are routinely backported. By not changing the behavior, we are declaring it correct.
To me, this is the type of non-trivial doc change that should get a news entry to alert people who might want to read the new text to correct misunderstanding. So I think there should be another PR to do so.
pythongh-58749: Remove incorrect language spec claims about the globa…
pythongh-58749: Remove incorrect language spec claims about the globa…