scope of generators, class variables, resulting in global na

[Arnaud Delobelle]

dontspamleo <dontsendleospam at gmail.com> writes:

> Hi Arnaud et al,
>
> Here is the link to the bug report from which the discussion in PEP
> 289 was extracted:
>
> http://bugs.python.org/issue872326
>
> It looks like they were fixing a bunch of bugs and that this
> discussion was one of the many in that thread.
>
> Here is another post which points to the core of the issue: early/late
> binding. It is also pointed to in PEP 289.
>
> http://mail.python.org/pipermail/python-dev/2004-April/044555.html

Thanks for digging those out!

> Here is Guido's rationale (his text is the items (a) and (b) below. My
> comments follow.
>
> (a) I find it hard to defend automatic variable capture given Python's
>     general late-binding semantics
>
> MY COMMENTS: That is a good point. There are however exceptions to the
> "general late-binding semantics" (GLBS) in Python. The outer loop does
> bind early in this case in fact. A point to consider along with GLBS
> is the unintuitive early bind of the external iterator vs late bind of
> the internal iterator. That is a function not of early vs. late
> binding, but of the current translation of generator expressions to
> generator functions. Using Arnaud's approach would fix that and make
> the code IMO so more pythonic.

But see this message from Guido:

http://bugs.python.org/issue872326#msg45190

It looks like he's thinking of early binding of free variables.  Later
on he seems to contradict this.

Below it is mentioned that two patches were made, one with the current
behaviour and one with the one you (and I) would prefer.

> (b) I believe that use cases needing early binding are uncommon and
>     strained: they all involve creating a list of generator
>     expressions, which IMO is a pretty unusual thing to do
>
> MY COMMENTS: This is actually a pretty common use case. Any iteration
> over objects of arity 2 or greater (A matrix, a table, a tree searched
> breadthwise under some data structures, etc.) can conveniently and
> cleanly be expressed using a generator expression.

And also your example when defining a generator expression in a class
scope becomes confusing with the current semantics.

> I'd also add that perhaps the title of Guido's post: "Generator
> Expressions - Let's Move Forward" may have unintentionally discouraged
> people from reexamining the issue.
>
> I would like to see this decision revisited. Obviously before spending
> any time on this I'd like to gauge if there is further interest. Am I
> off the mark? Maybe there is a technical misunderstanding on my part.
> If there are more people affected (Since the last week I found some
> other postings here and on other lists and blogs) who can make a clear
> case, then what is the next step?

I suppose it would be interesting to see how this can be implemented,
maybe look at the gexp.diff.capture file on the bug tracker.  I was
intending to look into it a couple of years ago but I could never find
the time :(

-- 
Arnaud