Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dict comprehension shouldn't raise UnboundLocalError #75309

Closed
ksqsf mannequin opened this issue Aug 6, 2017 · 5 comments
Closed

dict comprehension shouldn't raise UnboundLocalError #75309

ksqsf mannequin opened this issue Aug 6, 2017 · 5 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@ksqsf
Copy link
Mannequin

ksqsf mannequin commented Aug 6, 2017

BPO 31126
Nosy @bitdancer, @eryksun

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 = <Date 2017-08-06.14:26:54.889>
created_at = <Date 2017-08-06.13:17:16.610>
labels = ['interpreter-core', 'type-bug', 'invalid']
title = "dict comprehension shouldn't raise UnboundLocalError"
updated_at = <Date 2017-08-06.23:07:21.809>
user = 'https://bugs.python.org/ksqsf'

bugs.python.org fields:

activity = <Date 2017-08-06.23:07:21.809>
actor = 'eryksun'
assignee = 'none'
closed = True
closed_date = <Date 2017-08-06.14:26:54.889>
closer = 'eryksun'
components = ['Interpreter Core']
creation = <Date 2017-08-06.13:17:16.610>
creator = 'ksqsf'
dependencies = []
files = []
hgrepos = []
issue_num = 31126
keywords = []
message_count = 5.0
messages = ['299799', '299800', '299801', '299807', '299818']
nosy_count = 3.0
nosy_names = ['r.david.murray', 'eryksun', 'ksqsf']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue31126'
versions = ['Python 3.6']

@ksqsf
Copy link
Mannequin Author

ksqsf mannequin commented Aug 6, 2017

The code
key = ["a", "b"]
val = [1, 2]
dic = {key:val for key in key for val in val}
will raise UnboundLocalError in Python 3.6.2 and 2.7.13.

Intuitively, the element 'key' and the list 'key' are not the same, so generally the expected result is {"a": 1, "b": 2}.

There are similar cases for listcomps, setcomps and genexprs:
l = [1, 2, 3]
{l for l in l} # => {1, 2, 3}
[l for l in l] # => [1, 2, 3]
for l in (l for l in l):
print(l, end=' ')
# => 1 2 3
All of them do as what is expected.

For consistency and intuitiveness, the behavior of distcomps should be modified so that no UnboundLocalError is raised.

@ksqsf ksqsf mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error labels Aug 6, 2017
@bitdancer
Copy link
Member

The behavior is consistent:

>>> a = [1, 2]
>>> b = [3, 4]
>>> [(a, b) for a in a for b in b]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <listcomp>
UnboundLocalError: local variable 'b' referenced before assignment

I'm not sure why it is only the nested loop that raises the error (https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries seems to imply it should raise for both)

By the way, the actual result of your comprehesion would be {"a": 2, "b" 2}.

@eryksun
Copy link
Contributor

eryksun commented Aug 6, 2017

Comprehensions evaluate the iterator for the outermost loop in the surrounding scope. The iterators for all inner loops are evaluated in the local scope of the comprehension itself.

@eryksun eryksun closed this as completed Aug 6, 2017
@eryksun eryksun added the invalid label Aug 6, 2017
@bitdancer
Copy link
Member

I wonder if that explanation should be added to the doc section to which I pointed. I thought I'd remembered something like that being in there, but it isn't.

@eryksun
Copy link
Contributor

eryksun commented Aug 6, 2017

It's consistent with the behavior of generator expressions:

Variables used in the generator expression are evaluated lazily
when the __next__() method is called for the generator object
(in the same fashion as normal generators). However, the
leftmost for clause is immediately evaluated, so that an error
produced by it can be seen before any other possible error in
the code that handles the generator expression. Subsequent for
clauses cannot be evaluated immediately since they may depend
on the previous for loop. For example: (x*y for x in range(10)
for y in bar(x)).

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants