need help on need help on generator...

[Craig Ringer]

On Sat, 2005-01-22 at 12:20 +0100, Alex Martelli wrote:
> Craig Ringer <craig at postnewspapers.com.au> 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 - for some reason I hadn't clicked to that. Obvious in hindsight,
but I just completely missed it.

> > Might it be worth providing a way to have file objects seek back to the
> > current position of the iterator when read() etc are called? If not, I
> 
> It's certainly worth doing a patch and see what the python-dev crowd
> thinks of it, I think; it might make it into 2.5.

I'll certainly look into doing so. I'm not dumb enough to say "Sure,
I'll do that" before looking into the code involved and thinking more
about what issues could pop up. Still, it's been added to my
increasingly frightening TODO list.

> > favour the suggestion in the referenced post - file should probably fail
> > noisily, or at least emit a warning.
> 
> Under what conditions, exactly, would you want such an exception?

When read() or other methods suffering from the same issue are called
after next() without an intervening seek(). It'd mean another state flag
for the file to keep track of - but I doubt it'd make any detectable
difference in performance given that there's disk I/O involved.

I'd be happier to change the behaviour so that a warning isn't
necessary, though, and I suspect it can be done without introducing
backward compatibility issues. Well, so long as nobody is relying on the
undefined file position after using an iterator - and I'm not dumb
enough to say nobody would ever do that.

I've really got myself into hot water now though - I'm going to have to
read over the `file' source code before impulsively saying anything
REALLY stupid.

-- 
Craig Ringer