Generator Comprehensions? was Re: a break for comprehensions
kens at sightreader.com
Tue Jul 31 02:48:04 CEST 2001
"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
> for generators.
> I believe a separate syntax would be required to represent such a
> different object. But you, of course, may know better ... if you're
> for a syntax, one possibility would be:
> [[x * 2 for x in g()]]
That particular syntax won't do since it would seem to require two new
"[[" and "]]" which would be really nasty since there's already semantics
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
a list when a generator is being iterated, since the generator might be
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
More information about the Python-list