nested 'for' expression in list comprehensions no longer work

[cboos]

While debugging ​#T8440, I figured out it was Genshi not interpreting correctly the <py:for> expressions used ​there. Those are rather complex and ugly, but still... this used to work in 0.5.1.

Given the following unit-test:

genshi/template/tests/eval.py

@@ -264 +264 @@
         self.assertEqual([2, 3, 4, 5, 6],
                          expr.evaluate({'numbers': range(5), 'offset': 2}))
 
+        expr = Expression("[n for group in groups for n in group]")
+        self.assertEqual([0, 1, 0, 1, 2],
+                         expr.evaluate({'groups': [range(2), range(3)]}))
+
     def test_list_comprehension_with_getattr(self):
         items = [{'name': 'a', 'value': 1}, {'name': 'b', 'value': 2}]
         expr = Expression("[i.name for i in items if i.value > 1]")

which passes fine in 0.5.1 and 0.5.x of today, I get:

======================================================================
ERROR: test_list_comprehension (genshi.template.tests.eval.ExpressionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\workspace\src\trac\dependencies\genshi\upstream-trunk\genshi\template\tests\eval.py", line 263, in test_list_comprehension
    expr.evaluate({'groups': [range(2), range(3)]}))
  File "c:\workspace\src\trac\dependencies\genshi\upstream-trunk\genshi\template\eval.py", line 178, in evaluate
    return eval(self.code, _globals, {'__data__': data})
  File "<string>", line 1, in <Expression '[n for group in groups for n in group]'>
  File "c:\workspace\src\trac\dependencies\genshi\upstream-trunk\genshi\template\eval.py", line 305, in lookup_name
    val = cls.undefined(name)
  File "c:\workspace\src\trac\dependencies\genshi\upstream-trunk\genshi\template\eval.py", line 406, in undefined
    raise UndefinedError(key, owner=owner)
UndefinedError: "group" not defined

on trunk (r1063).

A quick bisection leads to r988 (what a surprise, the AST merge ;-) ).

[mgood]

Looking into it.

[mgood]

Hrm, contrary to the comments, the generator should *not* be handled in reverse order. Right now it's trying to process "for n in group" before "for group in groups", so it doesn't recognize "group" as a local variable and tries to look it up from the template context, which of course fails. I've got a patch including the above test, plus a test to ensure that it works when both loop variables are in the template context and not local to the loop.

[mgood]

Ok, fixed this in [1064].

[cboos]

Wow, great! Thanks for caring.