This may be a known consequence of python 3.0, but I couldn't find any reference to it, nor a test case that covers it. Here's a valid use of yield in 2.5.1: >>> def foo(): ... x=[(yield x) for x in 1,2,3] ... yield 5 ... yield x >>> x=foo() >>> x.next() 1 >>> x.send(6) 2 >>> x.send(7) 3 >>> x.send(8) 5 >>> x.send(9) [6, 7, 8] >>> x.send(10) Traceback (most recent call last): File "<stdin>", line 1, in <module> StopIteration But in python 3.0, this code results in: >>> def foo(): ... x=[(yield x) for x in (1,2,3)] ... yield 5 ... yield x >>> x=foo() >>> next(x) 5 >>> x.send(6) <generator object <listcomp> at 0x3678f0> >>> x.send(7) Traceback (most recent call last): File "<stdin>", line 1, in <module> StopIteration Looking further, it seems that this is a comprehension: >>> def foo(): [(yield 5)] >>> type(foo()) <class 'generator'> Whereas this is not: >>> def foo(): [(yield 5) for x in range(3)] >>> type(foo()) <class 'NoneType'> Is this expected behavior?

This is because list comprehensions are implemented as functions in 3.0 so their scope is not leaked out to the rest of the function. Here is the bytecode for 2.6: >>> dis.dis(f) 2 0 BUILD_LIST 0 3 DUP_TOP 4 STORE_FAST 0 (_[1]) 7 LOAD_CONST 5 ((1, 2, 3)) 10 GET_ITER >> 11 FOR_ITER 14 (to 28) 14 STORE_FAST 1 (x) 17 LOAD_FAST 0 (_[1]) 20 LOAD_FAST 1 (x) 23 YIELD_VALUE 24 LIST_APPEND 25 JUMP_ABSOLUTE 11 >> 28 DELETE_FAST 0 (_[1]) 31 STORE_FAST 1 (x) 3 34 LOAD_CONST 4 (5) 37 YIELD_VALUE 38 POP_TOP 4 39 LOAD_FAST 1 (x) 42 YIELD_VALUE 43 POP_TOP 44 LOAD_CONST 0 (None) 47 RETURN_VALUE and here it is for 3.0: >>> dis.dis(f) 2 0 LOAD_CONST 1 (<code object <listcomp> at 0x740770, file "<stdin>", line 2>) 3 MAKE_FUNCTION 0 6 LOAD_CONST 6 ((1, 2, 3)) 9 GET_ITER 10 CALL_FUNCTION 1 13 STORE_FAST 0 (x) 3 16 LOAD_CONST 5 (5) 19 YIELD_VALUE 20 POP_TOP 4 21 LOAD_FAST 0 (x) 24 YIELD_VALUE 25 POP_TOP 26 LOAD_CONST 0 (None) 29 RETURN_VALUE

Yes, this change in semantics is expected. Closing as "won't fix".