One use case which seems significant to me but I don’t think has been
explicitly mentioned is annotations using a package with stubs where the
stubbed typing API is slightly different than the runtime API.
For example sometimes additional tape aliases are defined for convenience in
stubs without a corresponding runtime name, or a class is generic in the stubs
but has not yet been made to inherit typing.Generic (or just made a
subscriptable class), in runtime. These situations are described in the mypy
docs:
https://mypy.readthedocs.io/en/latest/runtime_troubles.html#using-classes-that-are-generic-in-stubs-but-not-at-runtime.
These are easy to write without problems using PEP 563, but I am not sure how
they would work with PEP 649.
I believe this pattern may be useful in complex existing libraries when typing
is added, as it may be difficult to convert an existing class to generic. For
example with numpy, the core ndarray class was made generic in stubs to support
indicating the shape and data type. You could only write eg ndarray[Any,
np.int64] using PEP 563. A while later a workaround was added by defining
__class_getitem__.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/IJ37JVIVVGN5BJGMMNKGADXBYUSMVU6F/
Code of Conduct: http://python.org/psf/codeofconduct/
