Skip to content

BytesIO.name and StringIO.name should not be defined #1790

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
srittau opened this issue Dec 17, 2017 · 4 comments
Closed

BytesIO.name and StringIO.name should not be defined #1790

srittau opened this issue Dec 17, 2017 · 4 comments

Comments

@srittau
Copy link
Collaborator

srittau commented Dec 17, 2017 •
edited by gvanrossum
Loading

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 = name

mypy 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 = name

This 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'
@gvanrossum
Copy link
Member

Ow, this cuts deep. It seems class IO defined in types.py has a name property. 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 of types.IO.

@srittau
Copy link
Collaborator Author

srittau commented Dec 21, 2017

A previous issue that discussed StringIO.name: #598.

@gvanrossum
Copy link
Member

Rather than trying to fix the deep issues (which seem impossibly hard) let's just add

name = ...  # type: str

to BytesIO so it matches the hack we have for StringIO.

@gvanrossum
Copy link
Member

(Can you make a PR?)

srittau added a commit to srittau/typeshed that referenced this issue Jan 2, 2018
@srittau
Add StringIO.name and BytesIO.name
717fb35 
Also, change the type of StringIO.name (Python 3) from str to Any.

Neither StringIO nor BytesIO actually define a name field, but the
super-class IO[T] of both in typeshed does define a read-only property.
This means that sub-classes of StringIO and BytesIO adding this field
will not typecheck correctly.

Closes: python#1790
@srittau srittau mentioned this issue Jan 2, 2018
Merged
JelleZijlstra pushed a commit that referenced this issue Jan 26, 2018
@srittau @JelleZijlstra
Add StringIO.name and BytesIO.name (#1802)
6d7173b 
Also, change the type of StringIO.name (Python 3) from str to Any.

Neither StringIO nor BytesIO actually define a name field, but the
super-class IO[T] of both in typeshed does define a read-only property.
This means that sub-classes of StringIO and BytesIO adding this field
will not typecheck correctly.

Closes: #1790
@sastels sastels mentioned this issue Feb 27, 2018
Merged
@arifulhaqueHO arifulhaqueHO mentioned this issue Aug 9, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@srittau @gvanrossum