This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vinay.sajip
Recipients Arfrever, amaury.forgeotdarc, benjamin.peterson, georg.brandl, vinay.sajip
Date 2011-06-19.21:10:21
SpamBayes Score 1.0433524e-07
Marked as misclassified No
Message-id <1308517822.49.0.989383264119.issue12291@psf.upfronthosting.co.za>
In-reply-to
Content
@Benjamin: I missed commenting on your "Why not 0?", but here's the reasoning: one can't assume that the file only contains one object to be read, at the beginning of the file. It may be that some data is being written to file using marshal.dump, interspersed with other data, and then the stream is being read in at a later time, with marshal.load called to load a previously saved object. In that scenario, why would 0 be always the correct offset value to pass to fseek?

I am synchronising the Python object with the FILE *, but not the other way around - in the failing case I mentioned, external Python code has positioned the io object to zero, but that of course will be overwritten to point the io object back to where the FILE object is positioned. Perhaps I just need to go the other way ...

I'm not sure how reliable a solution will be which tries to work around there apparently being two buffering implementations - at the io level and at the FILE level, and trying to keep them synced in a seemingly ad hoc fashion.

It's perfectly possible that I don't know what I'm talking about, so I'd welcome an improved patch using the ideas you've suggested. It's been a very long time since I wrote C stdio code regularly ;-)
History
Date User Action Args
2011-06-19 21:10:22vinay.sajipsetrecipients: + vinay.sajip, georg.brandl, amaury.forgeotdarc, benjamin.peterson, Arfrever
2011-06-19 21:10:22vinay.sajipsetmessageid: <1308517822.49.0.989383264119.issue12291@psf.upfronthosting.co.za>
2011-06-19 21:10:21vinay.sajiplinkissue12291 messages
2011-06-19 21:10:21vinay.sajipcreate