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.

Title: io.BytesIO.truncate does not work as advertised
Type: behavior Stage: needs patch
Components: IO, Library (Lib) Versions: Python 3.6, Python 3.5, Python 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: alexandre.vassalotti, anton.barkovsky, justus.winter, martin.panter, serhiy.storchaka, xiang.zhang, xtreak
Priority: normal Keywords:

Created on 2016-06-07 20:52 by justus.winter, last changed 2022-04-11 14:58 by admin.

Messages (5)
msg267748 - (view) Author: Justus Winter (justus.winter) Date: 2016-06-07 20:52
% python3.6 -c "import io; b=io.BytesIO(); assert b.truncate(42) == 42; assert len(b.getbuffer()) == 42, 'expected length 42, got {}'.format(len(b.getbuffer()))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AssertionError: expected length 42, got 0

The documentation [0] says that truncate can extend objects, and there is no indication that BytesIO does not support that.  As demonstrated, truncate returns the new size, but the buffer obtained from that BytesIO is of size zero (likewise, b.getvalue() returns b''.

msg267758 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-06-08 01:00
BytesIO is supposed to implement IOBase. I would treat this as a bug in existing versions too.
msg267765 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016-06-08 03:01
Is this a bug or a documentation matter? Inspecting BytesIO.truncate's code, it does resizing similar to list, this seems to be a designed feature, which conflicts with the documented behaviour.
msg267848 - (view) Author: Justus Winter (justus.winter) Date: 2016-06-08 13:41
FWIW, I consider the documented behavior a feature.  My use case is to allocate a BytesIO object with a given size, obtain a view to its buffer, and write to it from a c library.
msg327578 - (view) Author: Anton Barkovsky (anton.barkovsky) * Date: 2018-10-12 10:55
I'm willing to try to fix this behavior.

I just want to check that this would not be considered breaking backwards compatibility. I can imagine in theory some code relying on it, but I would say that it would be relying on a bug. If some code is passed BytesIO in place of a file, then the current behavior is clearly undesirable. If some code specifically uses BytesIO and relies on this... I guess this can happen, but should be very rare and contrary to widely documented behavior. So it seems ok to just fix this, but I'm not very familiar with how such changes are usually handled in cPython, so I'd like to get approval from someone experienced.
Date User Action Args
2022-04-11 14:58:32adminsetgithub: 71448
2018-10-12 10:55:18anton.barkovskysetmessages: + msg327578
2018-10-12 09:25:38anton.barkovskysetnosy: + anton.barkovsky
2018-09-23 15:15:25xtreaksetnosy: + xtreak
2016-06-08 13:41:11justus.wintersetmessages: + msg267848
2016-06-08 03:02:25xiang.zhangsetnosy: + alexandre.vassalotti, serhiy.storchaka
2016-06-08 03:01:50xiang.zhangsetnosy: + xiang.zhang
messages: + msg267765
2016-06-08 01:00:12martin.pantersetversions: + Python 2.7, Python 3.5
nosy: + martin.panter

messages: + msg267758

stage: needs patch
2016-06-07 20:52:57justus.wintercreate