Limit "global" keyword name conflicts in language spec to those enforced by CPython

[ncoghlan]

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']

Linked PRs

• gh-58749: Removes the erroneous explanation regarding the restrictions of the global statement #126523
• gh-58749: Add test_nonlocal.py to ensure correct behavior of nonlocal statements and add NEWS entries #126738

[ncoghlan]

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]

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]

Thread link: http://mail.python.org/pipermail/python-ideas/2012-April/014783.html

[rhettinger]

+1 for the proposed change. It should add there is also an enforced (and obvious) restriction that the variable not have been declared nonlocal.

[ncoghlan]

Thanks for the PR @bombs-kim! The inaccurate statements in the language spec have now been fixed for 3.14. It looks like the nonlocal statement never had the incorrect information added, so it doesn't need any updates.

Open items before we close out this issue:

• adding test_nonlocal.py to mirror the test_global.py test cases (behaviour is essentially the same, everything just needs to be pushed down into a nested function so it can use a nonlocal statement referring to a method level name_for_test_case = None local name instead of a global one. The equivalent of looking up the name in globals() for these tests will be to look up f.__closure__[0].cell_contents (assuming the nested functions are just called f)
• adding a Documentation NEWS entry (we didn't change the behaviour of the language, but we did fix an error in the language spec)
• adding a Tests NEWS entry (we added test cases to ensure implementations abide by the updated wording)
• deciding whether the change should be backported to 3.13 or not (I'm leaning towards "no" on that one - while it's highly unlikely that any interpreter implementation is actually enforcing the old nominal behaviour, adjusting part of the language spec doesn't feel like a "maintenance release" level change either)