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/
