Unsoundness with `typing.IO` and friends

The classes typing.IO, typing.BinaryIO, and typing.TextIO look like they want to be Protocols or ABCs, but in fact they are defined as regular generic classes, both at runtime and in typeshed. However, they are meant to encompass the concrete IO classes defined in the io module, and in typeshed we implement that by having these classes inherit from typing.*IO classes, even though there is no such inheritance at runtime.

This can easily lead to unsound behavior:

import io, typing

def f(x: int | io.BytesIO) -> int:
    if isinstance(x, typing.BinaryIO):
        return x.fileno()
    return x

f(io.BytesIO()) + 1  # boom

Type checkers think BytesIO is a subclass of BinaryIO, because that's how it's defined in typeshed, but in fact it isn't at runtime.

I can see a few solutions:

1. Special-case typing.*IO in the spec and say that type checkers should reject isinstance()/issubclass() calls involving them.
2. Deprecate the typing.*IO classes and eventually remove them, nudging people to use their own Protocols (or the new io.Reader/io.Writer) instead. This is conceptually clean but may be annoying for a lot of users; the typing classes are nice to use in simple application code.
3. Make these classes actually (runtime-checkable?) Protocols at runtime, though they would be unwieldily large.

Even if we do (2) or (3) type checkers might still want to do (1) since it will be a while before the relevant runtime changes take effect.

(Noticed this while looking into https://github.com/python/cpython/issues/133492 .)

Commencez par examiner le comportement à l’exécution de typing.IO, typing.BinaryIO, typing.TextIO et io.BytesIO, ainsi que leurs relations dans typeshed et l’issue CPython associée. Comparez les trois approches proposées et documentez ou implémentez une spécification et une orientation d’exécution convenues ; la tâche ne sera considérée comme terminée qu’après avoir déterminé le comportement attendu de isinstance() et issubclass().