Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
On Sat, Dec 26, 2020 at 02:19:55AM +0000, Terry J. Reedy wrote:
> "Enhancements" (non-bugfix feature changes) can only be applied to
> future versions. However, you are asking for the reversion of an
> intentional feature change made in a 'bugfix' release# for (I believe)
> 3.1. Before the change, as I remember, truncating to 0 *did* move the
> file pointer back to 0. As I remember, Guide von Rossum requested the
> change and Antoine Pitrou made it.
Thanks for that insight Terry. I think the current behaviour is correct.
Sparse files can have holes in them, and non-sparse files have to be
filled with NUL bytes, so this has to work:
f.truncate(0)
f.seek(10)
f.write('x')
# File is now ten NUL bytes and a single 'x'
If you swap the order of the truncate and the seek, the behaviour
shouldn't change: truncate is documented as not moving the file
position, so changing this will be backwards incompatible and will
probably break a lot of code that expects the current behaviour.
https://docs.python.org/3/library/io.html#io.IOBase.truncate
I agree with Terry rejecting this feature request. If 施文峰 (Shīwén
Fēng according to Google translate) wishes to disagree, this will have
to be discussed on the Python-Ideas mailing list first.
----------
title: [issue] io's r+ mode truncate(0) -> io's r+ mode truncate(0)
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue42733>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
