need help on need help on generator...

[Francis Girard]

Really, thank you Craig Ringer for your great answer.


> I'm afraid I can't help you with that. I tend to take the view that side
> effects in lazily executed code are a bad plan, and use lazy execution
> for things where there is no reason to care when the code is executed.


I completly agree with this. But this is much more true in theory than in 
practice. In practice you might end up with big big memory usage with lazy 
constructs as the "system" has to store intermediate results (the execution 
context in the case of Python). These kinds of phenomena happen all the time 
in a language like Haskell -- at least for a beginner like me -- if you don't 
pay attention to it ; and this makes the language a lot more difficult to 
master. Thus you have to keep an eye on performance even though, in FP, you 
shoould just have to "declare" your intentions and let the system manage the 
execution path.


>     http://gnosis.cx/publish/programming/metaclass_1.html
>     http://gnosis.cx/publish/programming/metaclass_2.html

Thank you, I'll read that.

Francis Girard
FRANCE

Le vendredi 21 Janvier 2005 16:42, Craig Ringer a écrit :
> On Fri, 2005-01-21 at 16:05 +0100, Francis Girard wrote:
> > I recently read David Mertz (IBM DeveloperWorks) about generators and
> > got excited about using lazy constructs in my Python programming.
>
> Speaking of totally great articles, and indirectly to lazyness (though
> not lazyily evaluated constructs), I was really impressed by this
> fantastic article on metaclasses:
>
>     http://gnosis.cx/publish/programming/metaclass_1.html
>     http://gnosis.cx/publish/programming/metaclass_2.html
>
> which shows that they're really just not that hard. That saved me an
> IMMENSE amount of utterly tedious coding just recently.
>
> > But besides the fact that generators are either produced with the new
> > "yield" reserved word or by defining the __new__ method in a class
> > definition, I don't know much about them.
>
> They can also be created with a generator expression under Python 2.4. A
> generator expression works much like a list comprehension, but returns a
> generator instead of a list, and is evaluated lazily. (It also doesn't
> pollute the outside namespace with its working variables).
>
> >>> print [ x for x in range(1,10)]
>
> [1, 2, 3, 4, 5, 6, 7, 8, 9]
>
> >>> print ( x for x in xrange(1,10) )
>
> <generator object at 0x401e40ac>
>
> >>> print list(( x for x in xrange(1,10) ))
>
> [1, 2, 3, 4, 5, 6, 7, 8, 9]
>
> Not the use of xrange above for efficiency in the generator expressions.
> These examples are trivial and pointless, but hopefully get the point
> across.
>
> > In particular, I don't know what Python constructs does generate a
> > generator.
>
> As far as I know, functions that use yield, and generator expressions. I
> was unaware of the ability to create them using a class with a __new__
> method, and need to check that out - I can imagine situations in which
> it might be rather handy.
>
> I'm not sure how many Python built-in functions and library modules
> return generators for things.
>
> > I know this is now the case for reading lines in a file or with the
> > new "iterator" package. But what else ? Does Craig Ringer answer mean
> > that list comprehensions are lazy ?
>
> Nope, but generator expressions are, and they're pretty similar.
>
> > Where can I find a comprehensive list of all the lazy constructions
> > built in Python ? (I think that to easily distinguish lazy from strict
> > constructs is an absolute programmer need -- otherwise you always end
> > up wondering when is it that code is actually executed like in
> > Haskell).
>
> I'm afraid I can't help you with that. I tend to take the view that side
> effects in lazily executed code are a bad plan, and use lazy execution
> for things where there is no reason to care when the code is executed.
>
> --
> Craig Ringer