Suggestion for impriving list comprehensions

Steven D. Majewski sdm7g at Virginia.EDU
Fri Jul 27 02:53:34 CEST 2001


On Thu, 26 Jul 2001, Guido van Rossum wrote:

> paul at svensson.org (Paul Svensson) writes:
> 
> > I would like to suggest that we add a "while condition" clause
> > to list comprehensions, similar to the "if condition" clause,
> > but terminating the list comprehension on the first false condition.
> > The above example could then be written as
> > 
> > [x for x in fib() while x < 50]
> 
> Neat, but maybe not general enough.  How do you request the first N?
> And fuzzy: does this include or exclude the first x >= 50?
> 
> How about a library of functions for iterator algebra?  E.g.
> 

How about:

>>> def dowhile( seq, test ):
...     for x in seq: 
...             if test(x): yield x
...             else: break 
... 
>>> def until( seq, test ):
...     for x in seq:
...             yield x
...             if test(x) : break 
... 
>>> [ x for x in until( range(100), lambda x: x > 12 ) ]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13]
>>> [ x for x in until( fib(), lambda x: x > 50 ) ]
[1, 1, 2, 3, 5, 8, 13, 21, 34, 55]
>>> [ x for x in dowhile( fib(), lambda x: x < 50 ) ] 
[1, 1, 2, 3, 5, 8, 13, 21, 34]
>>> 

( where fib is the generator version )


And maybe, Icon inspired:

>>> def every( s ):
...     return [ x for x in s ] 


>>> every( range(10) )
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> every( iter( fib().next, 55 ) )
[1, 1, 2, 3, 5, 8, 13, 21, 34]
>>> every( dowhile( fib(), lambda x: x < 50 ))
[1, 1, 2, 3, 5, 8, 13, 21, 34]
>>> 



If there was a version of iter that was:
	iter( genfunc, boolfunc )
along with:
	iter( genfunc, sentinal )

But checking for whether the second arg is callable is no good
if it's possible to iterate thru functions,methods or classes. 

Maybe a three arg version: 
	iter( genfunc, sentinal, boolfunc ) 

and if you don't care about the sentinal, pass an arg that won't
be produced by the generator. ( None maybe, depending. ) 

[ But maybe the generator versions above are better. 
  I'm still getting used to this new stuff. 
  Sometimes the syntax seems a bit awkward. 
  I hope that this __future__ stuff is not cast in stone until 
  we've had time to see how it works.  ] 


-- Steve Majewski






More information about the Python-list mailing list