Should it be possible to subclass TextIO without implementing all abstract methods?

[gvanrossum]

Currently this fails:

from typing import TextIO
class MyTextFile(TextIO):
    pass
f = MyTextFile()  # raises TypeError

The instantiation fails with TypeError: Can't instantiate abstract class MyTextFile with abstract methods <long list of methods>.

Mark Shannon pointed this out. I have to think about whether this is important to support; a simple work-around is to use TextIO.register() instead:

from typing import TextIO
class MyTextFile:
    pass
TextIO.register(MyTextFile)
f = MyTextFile()  # OK

[NYKevin]

Some (disjointed) thoughts:

• Does Mypy support register()?
• If we want to allow people to create subclasses without implementing <long list of methods>, why are they included in the abstract class? Could we make some of them mix-in methods instead?
• If we want to call any of <long list of methods>, and we have an instance of TextIO, should we be prepared to handle an AttributeError?
• I like the way the I/O system handles seekability in this regard (i.e. there's a seekable() method which returns True or False) -- could other features provide a similar API?
• What if we broke TextIO apart into a bunch of smaller abstract classes which do one thing each (e.g. TextReadable, TextWriteable, TextSeekable)?

[o11c]

Currently, the python2 stubs for cStringIO are forced to lie because read/write methods are not split into separate base classes. Doubtless there are many other cases, both in python2 and python3.

Suggest retitling to IO[AnyStr].

[srittau]

I believe this issue is obsolete by now, due to protocols and the suggestion to use protocols for I/O argument types.