"Francis Girard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>If I understand correctly,
Almost...
> a "generator" produce something over which you can
> iterate with the help of an "iterator".
To be exact, the producer is a generator function, a function whose body
contains
On Sat, 2005-01-22 at 12:20 +0100, Alex Martelli wrote:
> Craig Ringer <[EMAIL PROTECTED]> wrote:
>
> > .>>> data = ''.join(x for x in infile)
>
> Maybe ''.join(infile) is a better way to express this functionality?
> Avoids 2.4 dependency and should be faster as well as more concise.
Thanks - f
Craig Ringer <[EMAIL PROTECTED]> wrote:
> .>>> data = ''.join(x for x in infile)
Maybe ''.join(infile) is a better way to express this functionality?
Avoids 2.4 dependency and should be faster as well as more concise.
> Might it be worth providing a way to have file objects seek back to the
> c
Francis Girard <[EMAIL PROTECTED]> wrote:
...
> > A 'def' of a function whose body uses 'yield', and in 2.4 the new genexp
> > construct.
>
> Ok. I guess I'll have to update to version 2.4 (from 2.3) to follow the
> discussion.
It's worth upgrading even just for the extra speed;-).
> > Since
On Sat, 2005-01-22 at 17:46 +0800, I wrote:
> I'd be interested to know if there's a better solution to this than:
>
> .>>> inpath = '/tmp/msg.eml'
> .>>> infile = open(inpath)
> .>>> initer = iter(infile)
> .>>> headers = []
> .>>> for line in initer:
> if not line.strip():
>
Le samedi 22 Janvier 2005 10:10, Alex Martelli a ÃcritÂ:
> Francis Girard <[EMAIL PROTECTED]> wrote:
>...
>
> > 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 th
On Sat, 2005-01-22 at 10:10 +0100, Alex Martelli wrote:
> The answer for the current implementation, BTW, is "in between" -- some
> buffering, but bounded consumption of memory -- but whether that tidbit
> of pragmatics is part of the file specs, heh, that's anything but clear
> (just as for other
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 5. Several builtin functions return iterators rather than lists, specifically
> xrange(), enumerate() and reversed(). Other builtins that yield sequences
> (range(), sorted(), zip()) return lists.
Yes for enumerate and reversed, no for xrange:
>>> xx=xra
Francis Girard <[EMAIL PROTECTED]> wrote:
...
> 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.
Having __new__ in a class definition has nothing much to do with
Francis Girard wrote:
In particular, I don't know what Python constructs does generate a generator.
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 ? Where can I find a com
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 wi
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 construc
Hi,
I recently read David Mertz (IBM DeveloperWorks) about generators and got
excited about using lazy constructs in my Python programming.
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
13 matches
Mail list logo
