Repository navigation
BytesIO.name and StringIO.name should not be defined #1790
Description
Please consider the following Python 3.6 code:
from io import BytesIO
class NamedBytesIO(BytesIO):
def __init__(self, content: bytes, name: str) -> None:
super().__init__(content)
self.name = namemypy 0.560 complains:
test.py:8: error: Property "name" defined in "NamedBytesIO" is read-only
This is due to the fact that in typeshed BytesIO derives from BinaryIO, which defines the name property. The actual BytesIO implementation does not have such an attribute:
>>> from io import BytesIO
>>> BytesIO(b"").name
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: '_io.BytesIO' object has no attribute 'name'
Interestingly, StringIO does not have this problem:
from io import StringIO
class NamedStringIO(StringIO):
def __init__(self, content: str, name: str) -> None:
super().__init__(content)
self.name = nameThis checks fine with mypy, since the StringIO stub includes a name field, which also does not match the implementation:
>>> from io import StringIO
>>> StringIO("").name
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: '_io.StringIO' object has no attribute 'name'
Activity
gvanrossum commentedon Dec 17, 2017
Ow, this cuts deep. It seems class
IOdefined intypes.pyhas anameproperty. This is one of the problems with poorly specified protocols like IO -- we guess at what's part of the spec and what isn't. We'll probably need another helper class to represent the kinds of files returned by open(), and tighten up the spec oftypes.IO.srittau commentedon Dec 21, 2017
A previous issue that discussed
StringIO.name: #598.gvanrossum commentedon Dec 31, 2017
Rather than trying to fix the deep issues (which seem impossibly hard) let's just add
to
BytesIOso it matches the hack we have forStringIO.gvanrossum commentedon Dec 31, 2017
(Can you make a PR?)
Add StringIO.name and BytesIO.name
Add StringIO.name and BytesIO.name (#1802)