io.IncrementalNewlineDecoder is not a subclass of codecs.IncrementalDecoder

[tungol]

The documentation says that this class "inherits codecs.IncrementalDecoder", but it's not true for the C implementation.

The python implementation, _pyio.IncrementalNewlineDecoder, does inherit from codecs.IncrementalDecoder, but that's not the implementation that you get with from io import IncrementalNewlineDecoder.

cpython has a ticket for this issue here: python/cpython#75903

In the meantime, I think this is more correct.

Related to #3968

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[tungol]

A little more investigation shows that the situation with io.BufferedRandom and io.StringIO is very similar. Typeshed is currently following inheritance given in the documentation and/or python implementation, not the C implementation. That said, those two are slightly muddier, so I'll wait and see what kind of reception this MR gets before doing anything about those two.

[AlexWaygood]

We should be careful here. I imagine the intention might be for these io classes to be "abstract" subclasses of the superclasses given in the docs (they implement the interface of the superclass even if they don't actually have the superclass in their mro at runtime). It might be a good idea to keep the fake inheritance here, for the same reason that we should keep pretending that builtins.list inherits directly from typing.MutableSequence

[tungol]

That makes sense. It seems like the main reason it isn't a subclass right now is that it's difficult to subclass a python implementation from a C implementation. I think you're right that the intention is there. I'll close this out for now.

[JelleZijlstra]

We should be careful here. I imagine the intention might be for these io classes to be "abstract" subclasses of the superclasses given in the docs (they implement the interface of the superclass even if they don't actually have the superclass in their mro at runtime). It might be a good idea to keep the fake inheritance here, for the same reason that we should keep pretending that builtins.list inherits directly from typing.MutableSequence

Not sure I agree. It's important to get inheritance right so that type checkers can treat isinstance() calls on these classes correctly. isinstance([], collections.abc.MutableSequence) is true at runtime (because of ABC registration), but as I understand that's not the case here.

[AlexWaygood]

I didn't actually mean my comment as a "This is wrong, close this now" kind of thing, more of a "Beware of Chesterton's fence" kind of thing. Feel free to reopen if I'm incorrect here, I haven't looked too deeply at this yet!

[tungol]

I didn't take your comment that way, for what it's worth. I closed this ticket because there's a bunch of other inheritance issues I'm working through, too. Once I've cleared out more of the easier cases, I'll probably revisit this.