Re: Lazy "for line in f" ?

Duncan Booth <[EMAIL PROTECTED]> wrote: > or even: > >read = f.readline >while read(): >pass > Oops, I forgot the other obvious variant on this, which has the benefit of getting rid of the test I said was 'required' while still leaving the data accessible: for line in ite

Re: Lazy "for line in f" ?

On Jul 23, 12:18 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > > Whatever, the iterator makes the code both cleaner and faster. It is at > the expense of not being suitable for interactive sessions, or in some > cases pipes, but for those situations you can continue to use readline > and the extra

Re: Lazy "for line in f" ?

Alexandre Ferrieux <[EMAIL PROTECTED]> wrote: > On Jul 23, 10:33 am, Duncan Booth <[EMAIL PROTECTED]> > wrote: >> >> The extra buffering means that iterating over a file is about 3 times >> faster than repeatedly calling readline. >> >> while 1: >> line = f.readline() >> if not

Re: Lazy "for line in f" ?

On Jul 23, 10:33 am, Duncan Booth <[EMAIL PROTECTED]> wrote: > > The extra buffering means that iterating over a file is about 3 times > faster than repeatedly calling readline. > > while 1: > line = f.readline() > if not line: > break > > for line in f: >

Re: Lazy "for line in f" ?

Alexandre Ferrieux <[EMAIL PROTECTED]> wrote: > On Jul 23, 9:36 am, Paul Rubin wrote: >> Alexandre Ferrieux <[EMAIL PROTECTED]> writes: >> > So I'll reiterate the question: *why* does the Python library add that >> > extra layer of (hard-headed) buffering on top of stdi

Re: Lazy "for line in f" ?

On Jul 23, 9:36 am, Paul Rubin wrote: > Alexandre Ferrieux <[EMAIL PROTECTED]> writes: > > So I'll reiterate the question: *why* does the Python library add that > > extra layer of (hard-headed) buffering on top of stdio's ? > > readline? I know readline() doesn't have t

Re: Lazy "for line in f" ?

Alexandre Ferrieux <[EMAIL PROTECTED]> writes: > So I'll reiterate the question: *why* does the Python library add that > extra layer of (hard-headed) buffering on top of stdio's ? readline? -- http://mail.python.org/mailman/listinfo/python-list

Re: Lazy "for line in f" ?

On Jul 23, 1:03 am, Steve Holden <[EMAIL PROTECTED]> wrote: > > What makes you think Python doesn't use the platform fgets()? The fact that it does that extra layer of buffering. Stdio is already buffered, duplicating this is useless. > ... in the case of file.next() (the file method called to >

Re: Lazy "for line in f" ?

Alexandre Ferrieux wrote: > On Jul 22, 7:21 pm, Miles <[EMAIL PROTECTED]> wrote: >> On 7/22/07, Alexandre Ferrieux wrote: >> >>> The Tutorial says about the "for line in f" idiom that it is "space- >>> efficient". >>> Short of further explanation, I interpret this as "doesn't read the >>> whole fi

Re: Lazy "for line in f" ?

On Jul 22, 7:21 pm, Miles <[EMAIL PROTECTED]> wrote: > On 7/22/07, Alexandre Ferrieux wrote: > > > The Tutorial says about the "for line in f" idiom that it is "space- > > efficient". > > Short of further explanation, I interpret this as "doesn't read the > > whole file before spitting out lines".

Re: Lazy "for line in f" ?

On 7/22/07, Alexandre Ferrieux wrote: > The Tutorial says about the "for line in f" idiom that it is "space- > efficient". > Short of further explanation, I interpret this as "doesn't read the > whole file before spitting out lines". > In other words, I would say "lazy". Which would be a Good Thin

Re: Lazy "for line in f" ?

On Sun, Jul 22, 2007 at 09:10:50AM -0700, Alexandre Ferrieux wrote: > I'm a total newbie in Python, but did give quite a try to the > documentation before coming here. > Sorry if I missed the obvious. > > The Tutorial says about the "for line in f" idiom that it is "space- > efficient". > Short of

Lazy "for line in f" ?

Hi, I'm a total newbie in Python, but did give quite a try to the documentation before coming here. Sorry if I missed the obvious. The Tutorial says about the "for line in f" idiom that it is "space- efficient". Short of further explanation, I interpret this as "doesn't read the whole file before