[Python-ideas] With clauses for generator expressions

[Andrew Barnert]

From: Terry Reedy <tjreedy at udel.edu>
Sent: Sun, November 18, 2012 11:56:04 AM


> On 11/17/2012 3:11 PM, Joshua Landau wrote:
> > On 17 November 2012 00:00,  Terry Reedy
> 
> >     OK, that's helpful. Now let me strip down  my objection to this: your
> >     proposal is conceptually wrong  because it mixes two distinct and
> >     different ideas --  collection definition and context management. It
> >     conflicts  with a well-defined notion of long standing.


> > I don't follow  how you made these two leaps:
> > * It doesn't apply to set comprehensions  in *math* -> it doesn't apply
> > to set comprehensions in  *Python*
> > * it doesn't apply to *set* comprehensions in Python -> it  doesn't apply
> > to *any* comprehensions in Python
> 
> Since the OP  withdrew his suggestion, its a moot point. 

I agree that it is a moot point. The idea would require a larger semantic change 
than I initially anticipated, and I disagree with Greg Ewing that the immediate 
evaluation of the outer source is a kluge that should be abandoned, so I've 
withdrawn it. (Of course if Greg Ewing or Joshua Landau or anyone else wants to 
pick up the idea, I apologize for presuming, but I no longer think it's a good 
idea.)

That's why I ignored the point about set builder notation. But if you want to 
continue to argue it:

> However, I 
> talked about the  general, coherent concept of comprehensions, as used in 
> both math and CS, as  an alternative to explicit listing. Do look at the 
> references, including the  Python manual. It presents the general idea 
> and implementation first and  then the four specific versions. I only 
> used sets for an example.


Nested comprehensions already break the analogy with set builder notation. For 
one thing, nobody would define the rationals as {i/j | j in Z: j != 0 | i in Z}. 
People would probably figure out what you meant, but you wouldn't write it that 
way. Nested comprehensions (even more so when one is dependent on the other) 
make it blatant that a comprehension is actually an iterative sequence builder, 
not a declarative set builder.

The analogy is a loose one, and it already leaks. It really only holds when 
you've got a single, well-ordered, finite source. It's obvious that (i/j for j 
in itertools.count(2) for i in range(1, j)) generates the rationals in (0, 1), 
in a specific order (with repeats), but you wouldn't write anything remotely 
similar in set builder notation. In fact, you'd probably define that set just as 
{q | i, j in N+: qj=i, q<1}, and you can't translate that to Python at all.