Fredrik Lundh wrote:
> copyfileobj copies from the current location, and write leaves the file
> pointer at the end of the file. a s.seek(0) before the copy fixes that.
Damn, this cannot be read from the documentation, and combined with the
fact that there's no length parameter for a portion to
Thomas Lotze wrote:
>> if you don't know how large f2 can be, use shutil.copyfileobj:
>>
>> >>> help(shutil.copyfileobj)
>> Help on function copyfileobj in module shutil:
>>
>> copyfileobj(fsrc, fdst, length=16384)
>> copy data from file-like object fsrc to file-like object fds
Fredrik Lundh wrote:
> if f2 isn't too large, reading lots of data in one operation is often the most
> efficient way (trust me, the memory system is a lot faster than your disk)
Sure.
> if you don't know how large f2 can be, use shutil.copyfileobj:
>
> >>> help(shutil.copyfileobj)
> He
Thomas Lotze wrote:
> f1.write(f2.read()) doesn't seem to me as efficient as it might be, as a
> string containing all the contents of f2 will be created and thrown away.
if f2 isn't too large, reading lots of data in one operation is often the most
efficient way (trust me, the memory system is a
Thomas Lotze wrote:
another question: What's the most efficient way of copying data between
two file-like objects?
f1.write(f2.read()) doesn't seem to me as efficient as it might be, as a
string containing all the contents of f2 will be created and thrown away.
You could try f1.writelines(f2).
Stev
Hi,
another question: What's the most efficient way of copying data between
two file-like objects?
f1.write(f2.read()) doesn't seem to me as efficient as it might be, as a
string containing all the contents of f2 will be created and thrown away.
In the case of two StringIO objects, this means the
