Generator Comprehensions? was Re: a break for comprehensions

[Ken Seehof]

"Steve Holden" <sholden at holdenweb.com> wrote:
> "Tom Good" <Tom_Good1 at excite.com> wrote in message
> news:ac677656.0107301331.5330d4db at posting.google.com...
> > "Steven D. Majewski" <sdm7g at Virginia.EDU> wrote in message
> news:<mailman.996515638.21022.python-list at python.org>...
> > >
> > > The 'while' clause seems useful, and I don't see anything inherently
> > > ambiguous about it, but sticking a procedural clause into what's
> > > otherwise a declarative seens to go against the spirit -- what's
> > > nice about list comprehensions is that they are just like set
> > > notations. ( well -- the left hand side is often procedural -- it
> > > would be even more readable if it were more clearly separated
> > > with a "where" clause, but that would be Yet Another Keyword... )
> > >
> > > -- Steve Majewski
> >
> > That is a compelling argument.  However, I am still struggling with
> > how to best work with infinite sets (which are now easy to create with
> > generators).  With set notation, you can refer to an infinite set
> > without actually creating each member of the set.  List comprehensions
> > try to "fill up" the list, which causes problems if an unbounded
> > generator is involved.
> >
> > If g is a generator that generates all positive integers, I would like
> > to write something like:
> >
> > L = [x * 2 for x in g()]
> > print L[:10]
> >
> > This does not work, of course, but that is how I would tend to think
> > about it in my head.  List comprehensions with lazy evaluation?  Is it
> > possible?
> >
> With the introduction of generators there doesn't seem to be anything
> inherently impossible about the introduction of such a concept. A major
> problem with existing list comprehensions, however, is that they produce a
> list! Seems that a "lazy comprehension" would have to encapsulate a
> generator somehow, and limit the operations you could perform on it to
those
> for generators.
>
> I believe a separate syntax would be required to represent such a
radically
> different object. But you, of course, may know better ... if you're
looking
> for a syntax, one possibility would be:
>
>     [[x * 2 for x in g()]]
>
> regards
>  Steve

That particular syntax won't do since it would seem to require two new
tokens
"[[" and "]]" which would be really nasty since there's already semantics
for those
character sequences (i.e. [[1,2,3]] is a list containing the list [1,2,3]).

You (Steve) are right IMO, that new language syntax would be required.  In
addition to the reasons you mention, it would not always unreasonable to
return
a list when a generator is being iterated, since the generator might be
finite.
Conversely, one might want a generator comprehension based on some other
arbitrary kind of sequence object.

How about [... x * 2 for x in g()]

- Ken Seehof