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 - 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 -- http://mail.python.org/mailman/listinfo/python-list