sys.stdout missing encoding attribute in Python 2

[mr-c]

typeshed/stdlib/2/sys.pyi

Line 73 in eef0b1d

stdout = ... # type: IO[str]

 python2
Python 2.7.15 (default, May  1 2018, 05:55:50) 
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> hasattr(sys.stdout, "encoding")
True
>>> dir(sys.stdout)
['__class__', '__delattr__', '__doc__', '__enter__', '__exit__', '__format__', '__getattribute__', '__hash__', '__init__', '__iter__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'close', 'closed', 'encoding', 'errors', 'fileno', 'flush', 'isatty', 'mode', 'name', 'newlines', 'next', 'read', 'readinto', 'readline', 'readlines', 'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines', 'xreadlines']
>>> from typing import IO
>>> hasattr(IO, "encoding")
False
>>> dir(IO)
['__abstractmethods__', '__args__', '__class__', '__delattr__', '__doc__', '__enter__', '__exit__', u'__extra__', '__format__', '__getattribute__', '__hash__', '__init__', '__metaclass__', '__module__', '__new__', '__next_in_mro__', '__orig_bases__', u'__origin__', '__parameters__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__slots__', '__str__', '__subclasshook__', '__tree_hash__', '_abc_cache', '_abc_generic_negative_cache', '_abc_generic_negative_cache_version', '_abc_registry', '_gorg', 'close', 'closed', 'fileno', 'flush', 'isatty', 'mode', 'name', 'read', 'readable', 'readline', 'readlines', 'seek', 'seekable', 'tell', 'truncate', 'writable', 'write', 'writelines']

typeshed/stdlib/2/typing.pyi

Line 277 in eef0b1d

class IO(Iterator[AnyStr], Generic[AnyStr]):

[JelleZijlstra]

Hm, at runtime sys.stdout is a file object, but builtins.file doesn't have the encoding attribute either in typeshed. We could make it a TextIO, but the Python 2 stub for that class also declares buffer and line_buffering, neither of which sys.stdout has.

I'm leaning towards using TextIO anyway so that we can fix your issue. Perhaps we need a bigger review of the file classes—it feels like there's a lot of variation in exactly what methods are supposed to exist on file-like objects.

[gvanrossum]

Hm, if we changed the declaration of sys.stdout to be TextIO then presumably sys.stdout = open(...) would fail because the latter returns a builtins.file which inherits from BinaryIO. And it's legal to assign instance of io.FileIO to sys.stdout, which does not have an encoding attribute.

So I'm tempted to say that (in Python 2!) the OP should not assume that sys.stdout.encoding exists, and if they nevertheless want to use it, they should probably # type: ignore it.

But I understand that's a pain.

[mr-c]

we need a bigger review of the file classes—it feels like there's a lot of variation in exactly what methods are supposed to exist on file-like objects.

👍

[srittau]

I feel that IO classes should be broken down into several fairly fine-grained protocols, considering how much variation there is. Most functions receiving a file-like object use only a fairly small subset of methods anyway (often just read() or readline()).

[gvanrossum]

Agreed. When I first designed the I/O hierarchy I resisted creating many small classes because the inheritance would be a nightmare. But with protocols this is actually the way to go, at least for arguments. For return values the existing hierarchy needs to continue to exist, since it matches the concrete types at runtime.

[srittau]

See also python/typing#564 for a broader discussion about this topic.

[AlexWaygood]

We now plan to soon remove support for Python 2 entirely (#7367), so I'm going to close this as a "wontfix" issue.