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 steven.daprano
Recipients ke265379ke, steven.daprano, terry.reedy
Date 2020-12-26.02:55:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20201226025515.GV28254@ando.pearwood.info>
In-reply-to <1608949195.36.0.0121566431562.issue42733@roundup.psfhosted.org>
Content
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.
History
Date User Action Args
2020-12-26 02:55:28steven.dapranosetrecipients: + steven.daprano, terry.reedy, ke265379ke
2020-12-26 02:55:28steven.dapranolinkissue42733 messages
2020-12-26 02:55:28steven.dapranocreate