You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
_pyio buffered classes raise AttributeError after detach() instead of ValueError #160472
After detach(), the pure-Python buffered classes in _pyio raise AttributeError
from the None raw stream, where the C implementations raise ValueError. The two
implementations therefore disagree on the kind of error, not just the wording.
so the class already knows the detached state, but only detach() itself checks
it. Every other method reaches self.raw and fails on the None, producing AttributeError: 'NoneType' object has no attribute '...'.
Expected behaviour
ValueError, matching the C implementation and matching the documented state of
the object ("After the raw stream has been detached, the buffer is in an unusable
state"). The check C performs is the CHECK_ATTACHED macro in Modules/_io/bufferedio.c.
Why it matters beyond error text
test_io runs the same test classes against both implementations (C and Py variants in Lib/test/test_io/), so any test that asserts ValueError for a
detached operation cannot be shared today. A _checkDetached() helper next to the
existing _checkClosed() would let those tests be written once.
Scope
I have not opened a patch, following the guidance in #160467 that the expected
behaviour should be agreed on the issue first. If the ValueError above is the
direction a triager wants, I can prepare the fix plus a test in test_textio.py
and test_bufferedio.py that runs against both implementations.
Found by differential testing _io against _pyio over random operation
sequences.
Activity
cmaloney commentedon Oct 23, 2026
Please read through https://devguide.python.org/getting-started/ai-tools/ in particular the "Considerations for success" section.
I'm going to close this as a duplicate of gh-160467. Both
_pyioand_ioshould have matching behavior (so a fix in one should happen in both).In general
_pyiois not at parity at the moment, I've actually requested permission to remove it python/steering-council#372.