I thought I’d try and assess how much of a problem the backward incompatibility is in practice. As stroxler mentions, mypy_primer is limited in its ability to assess whether switching to PEP 724 creates soundness holes. With that in mind, I went through the first ten projects in Code search results · GitHub
-
openai-python/src/openai/_utils/_utils.py at 66bab657c69dfebddbb4372adcdc97788cb3ceb1 · openai/openai-python · GitHub
unnecessary / trivial aliases for isinstance checks. 724 is safe -
sentry/src/sentry/utils/http.py at 1f687b72bf714e6a8aa9033a7d80b3a7e7401a98 · getsentry/sentry · GitHub
inventing a fictitious type for the type system to get good inference and narrowing with hasattr. 724 should be safe -
streamlit/lib/streamlit/type_util.py at 695958d8da781909a2ea724c83f6305056f853d3 · streamlit/streamlit · GitHub
several use cases. most common thing is like isinstance, but you pass a str so you don’t necessarily need to import things. some 724 unsafety around empty collections -
sqlalchemy/lib/sqlalchemy/sql/_typing.py at a8dbf8763a8fa2ca53cc01033f06681a421bf60b · sqlalchemy/sqlalchemy · GitHub
a lot of type discrimination based on attribute values (maybe could be accomplished by mixins + isinstance?). some narrowing with hasattr. 724 is likely safe. i didn’t go through all the uses in sqlalchemy. -
taipy/taipy/_run.py at 0877043a9fab3879dc04ff9d188dc7102a830ded · Avaiga/taipy · GitHub
filtering based on generic isinstance, looks a little useless (return type should be _AppTypeT). 724 should be safe -
PyGithub/github/GithubObject.py at 7e7653fb7cb054d3b03dd5f89dea1a2a79350827 · PyGithub/PyGithub · GitHub
some trivial isinstance + some checking collection elements. 724 should be safe -
tfx/tfx/utils/pure_typing_utils.py at b4ed9fd64baf5b9e3ae74a3e98e958c29970a050 · tensorflow/tfx · GitHub
runtime type checking. 724 should be safe -
pytorch/torch/serialization.py at cee16353db384dd33a4804f9f26829cacfcfbab7 · pytorch/pytorch · GitHub
trivial isinstance. 724 is safe -
core/homeassistant/helpers/service.py at 153c82c2d23b2589a0c68caeaca6947f831eb685 · home-assistant/core · GitHub
724 is unsafe for entity_match_none -
airflow/airflow/models/taskinstance.py at 44ba9008870eb63fb244793156da48e91cb17896 · apache/airflow · GitHub
724 is unsafe
(bonus, since it was mentioned in this thread)
- pip/src/pip/_internal/index/package_finder.py at main · pypa/pip · GitHub
typeguard
seems a little incorrectly used, but i think 724 is unsafe
Summary:
I was hoping for clarity, but I didn’t really get it. I did find real-world type guard functions where 724 semantics introduces potential for unsoundness where there previously wasn’t any. At the same time, none of these cases seem like particularly bad breakage — they weren’t public APIs and from what I could tell didn’t seem to be used in ways that the holes opened really mattered (although there’s survivorship bias when looking for buggy code).