exec fails to take locals into account when running list comprehensions or functions

[impact27]

BPO	41918
Nosy	@impact27, @havrikov

^{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 2020-10-03.09:06:43.988>
labels = ['type-feature', '3.7']
title = 'exec fails to take locals into account when running list comprehensions or functions'
updated_at = <Date 2020-11-29.17:03:44.495>
user = 'https://github.com/impact27'

bugs.python.org fields:

activity = <Date 2020-11-29.17:03:44.495>
actor = 'patterns'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2020-10-03.09:06:43.988>
creator = 'qpeter'
dependencies = []
files = []
hgrepos = []
issue_num = 41918
keywords = []
message_count = 5.0
messages = ['377862', '378614', '380876', '380877', '382077']
nosy_count = 4.0
nosy_names = ['qpeter', 'alex0kamp', 'havrikov', 'patterns']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue41918'
versions = ['Python 3.7']

[impact27]

The exec function fails to take locals into account when executing a list comprehension:

Python 3.7.7 (default, Mar 10 2020, 15:43:33) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> exec(compile('[my_var for i in range(1)]\n', '<stdin>', 'single'), {**globals(), "my_var": 0}, None)
[0]
>>> exec(compile('[my_var for i in range(1)]\n', '<stdin>', 'single'), globals(), {"my_var": 0})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <listcomp>
NameError: name 'my_var' is not defined
>>> 

This is the cause of https://bugs.python.org/issue21161

[impact27]

Fails for functions as well:

In [4]: exec(compile('print(my_var)\ndef a():\n print(my_var)\na()', '<stdin>', 'exec'), globals(), {"my_var": 0})
0
Traceback (most recent call last):

File "<ipython-input-4-f091e49f2781>", line 1, in <module>
exec(compile('print(my_var)\ndef a():\n print(my_var)\na()', '<stdin>', 'exec'), globals(), {"my_var": 0})

File "<stdin>", line 4, in <module>

 File "<stdin>", line 3, in a

NameError: name 'my_var' is not defined

[alex0kamp]

This seems to happen only when both arguments to exec are used:

Python 3.7.7 (default, Mar 10 2020, 15:43:27)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> exec('text = ["hallo"]\ntext.append("Welt")\nprint(" ".join([text[i] for i in range(0, 2)]))')
hallo Welt
>>> exec('text = ["hallo"]\ntext.append("Welt")\nprint(" ".join([text[i] for i in range(0, 2)]))', {})
hallo Welt
>>> exec('text = ["hallo"]\ntext.append("Welt")\nprint(" ".join(text))', {}, {})
hallo Welt
>>> exec('text = ["hallo"]\ntext.append("Welt")\nprint(" ".join([text[i] for i in range(0, 2)]))', {}, {})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in <module>
  File "<string>", line 3, in <listcomp>
NameError: name 'text' is not defined

[havrikov]

This issue also occurs in Python 3.8.6

[patterns]

Also occurs in Python 3.6.9

[oliverYoung2001]

This also occurs in Python 3.10.4 !!!

[rukayaj]

And 3.11.9

Example:

example = """
fields_a = ['testa0', 'test1']
fields_b = ['testb0', 'test1']
print(fields_a)
print(fields_b)
print([field for field in fields_a if field in fields_b])
"""
locals = {}
globals = {}
exec(example, globals, locals)

Gives error:

['testa0', 'test1']
['testb0', 'test1']
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "<string>", line 6, in <module>
  File "<string>", line 6, in <listcomp>
NameError: name 'fields_b' is not defined

I used this as a workaround:

locals = {}
globals = {}
combined_context = globals.copy()
combined_context.update(locals)
exec(example, combined_context, combined_context)

See also this more recent issue: #121306