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.

classification
Title: Explicit mention of raised ValueError's after .detach() of underlying IO buffer
Type: behavior Stage: resolved
Components: Documentation Versions: Python 3.9, Python 3.8, Python 3.7, Python 3.6, Python 3.5
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: docs@python Nosy List: bskinn, docs@python, iritkatriel
Priority: normal Keywords:

Created on 2019-07-29 03:34 by bskinn, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (3)
msg348594 - (view) Author: Brian Skinn (bskinn) * Date: 2019-07-29 03:34
Once the underlying buffer/stream is .detach()ed from an instance of a subclass of TextIOBase or BufferedIOBase, accession of most attributes defined on TextIOBase/BufferedIOBase or the IOBase parent, as well as calling of most methods defined on TextIOBase/BufferedIOBase/IOBase, results in raising of a ValueError.

Currently, the documentation of both .detach() methods states simply:

> After the raw stream has been detached, the buffer is in an unusable state.

I propose augmenting the above to something like the following in the docs for both .detach() methods, to make this behavior more explicit:

> After the raw stream has been detached, the buffer
> is in an unusable state. As a result, accessing/calling most
> attributes/methods of either :class:`BufferedIOBase` or its
> :class:`IOBase` parent will raise :exc:`ValueError`.

I confirm that the error raised for both `BufferedReader` and `TextIOWrapper` after `.detach()` *is* ValueError in all of 3.5.7, 3.6.8, 3.7.3, and 3.8.0b1.
msg407312 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-11-29 18:33
What is the advantage of making the doc more specific in this manner?

If we do change the doc like this, we need to add unit test ensuring that this is the behaviour, and we need are committing cpython (and all other python implementations) to behave like this in the future as well. 

I suggest this issue be rejected.
msg407315 - (view) Author: Brian Skinn (bskinn) * Date: 2021-11-29 18:37
Indeed, I hadn't been thinking about the testing/maintenance burden to CPython or other implementations when I made the suggestion.

I no longer have a strong opinion about this change, so I am happy to reject/close.
History
Date User Action Args
2022-04-11 14:59:18adminsetgithub: 81880
2021-11-29 18:37:26bskinnsetstatus: pending -> closed
resolution: rejected
messages: + msg407315

stage: resolved
2021-11-29 18:33:42iritkatrielsetstatus: open -> pending
nosy: + iritkatriel
messages: + msg407312

2019-07-29 03:35:26bskinnsettype: enhancement -> behavior
2019-07-29 03:34:58bskinncreate