homepage

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 random832
Recipients Zero, benjamin.peterson, docs@python, eryksun, fornax, martin.panter, pitrou, random832, serhiy.storchaka, socketpair, steve.dower, stutzbach
Date 2016年01月20日.04:31:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1453264290.88.0.751417733021.issue26158@psf.upfronthosting.co.za>
In-reply-to
Content
In the analogous C operations, ftell (analogous to .tell) actually causes the underlying file descriptor's position (analogous to the raw stream's position) to be reset to be at the same value that ftell has returned. Which means, yes, that you lose the benefits of buffering if you're so foolish as to call ftell after every read. But in this case the sequence "read / tell / truncate" would be analogous to "fread(f) / ftell(f) / ftruncate(fileno(f))
Though, the fact that fread operates on the FILE * whereas truncate operates on a file descriptor serves as a red flag to C programmers... arguably since this is not the case with Python, truncate on a buffered stream should implicitly include this same "reset underlying position" operation before actually performing the truncate.
History
Date User Action Args
2016年01月20日 04:31:31random832setrecipients: + random832, pitrou, benjamin.peterson, stutzbach, Zero, docs@python, socketpair, martin.panter, serhiy.storchaka, eryksun, steve.dower, fornax
2016年01月20日 04:31:30random832setmessageid: <1453264290.88.0.751417733021.issue26158@psf.upfronthosting.co.za>
2016年01月20日 04:31:30random832linkissue26158 messages
2016年01月20日 04:31:30random832create

AltStyle によって変換されたページ (->オリジナル) /