[Python-Dev] namespace for generator expressions

Jeremy Hylton jeremy at alum.mit.edu
Mon Jan 26 00:01:20 EST 2004

I'm happy to see progress on the generator expressions implementation,
but I think the specification of namespaces, which is just a sketch,
might be simplified.

The details begin by saying that a generator expression is equivalent to
creating an anonymous generator function and calling it.  Good!  I think
that will match an experienced programmer's intuition about how it

This simple model seems to be at odds with the later suggestion that all
free variables are bound using default argument values.  An anonymous
generator function would just have free variables, bound by the usual

The PEP suggests that a binding using default argument values is what
you want.  It's hard to argue one way or another without compelling
examples, but I think this is a case of special cases aren't special
enough to break the rules.  Are there any other cases where an
expression is evaluated using non-current bindings?  The only near
comparison is with list comprehensions, which aren't lazy, but do follow
the normal rules.

Any code that depends on what binding is used for a free variable is
going to be obscure.  The example in the PEP is contrived, of course,
but I can't imagine any code where it wouldn't be easy to achieve the
desired result by using a new variable that is not rebound after the
generator expression is defined.

Do you think there is any significant gain in expressiveness?  The PEP
says that no examples have been found where it would be better to use
the normal rule.  On the other hand, it doesn't show any examples
where's it's obviously better to use the proposed rule.

Another angle on this concern is the extra complexity it adds to the
language reference and to other explanations of the language's name
binding model (thinking of course materials, books, etc).  The new rules
adds non-trivial complexity to those rules, because we've got to
distinguish two kinds of code blocks that follow different rules for
free variables.


More information about the Python-Dev mailing list