# PEP 724: Stricter Type Guards

**URL:** <https://discuss.python.org/t/pep-724-stricter-type-guards/34124>\
**Category:** PEPs\
**Tags:** typing\
**Created:** [September 19, 2023, 4:06pm UTC](https://discuss.python.org/t/pep-724-stricter-type-guards/34124 "2023-09-19T16:06:06Z")\
**Posts on this page:** 1\
**Showing post:** 97

<div class="post-metadata">

**Author:** ![hauntsaninja](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hauntsaninja/32/12451_2.png) [@hauntsaninja](https://discuss.python.org/u/hauntsaninja)\
**Post date:** [February 5, 2024, 6:14am UTC](https://discuss.python.org/t/pep-724-stricter-type-guards/34124/97 "2024-02-05T06:14:48Z")

</div>

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](https://github.com/search?q=language%3Apython+%22-%3E+TypeGuard%5B%22&type=code)

> ****
>
> - [openai-python/src/openai/\_utils/\_utils.py at 66bab657c69dfebddbb4372adcdc97788cb3ceb1 · openai/openai-python · GitHub](https://github.com/openai/openai-python/blob/66bab657c69dfebddbb4372adcdc97788cb3ceb1/src/openai/_utils/_utils.py)  
> unnecessary / trivial aliases for isinstance checks. 724 is safe
> 
> - [sentry/src/sentry/utils/http.py at 1f687b72bf714e6a8aa9033a7d80b3a7e7401a98 · getsentry/sentry · GitHub](https://github.com/getsentry/sentry/blob/1f687b72bf714e6a8aa9033a7d80b3a7e7401a98/src/sentry/utils/http.py#L227)  
> 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](https://github.com/streamlit/streamlit/blob/695958d8da781909a2ea724c83f6305056f853d3/lib/streamlit/type_util.py)  
> 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](https://github.com/sqlalchemy/sqlalchemy/blob/a8dbf8763a8fa2ca53cc01033f06681a421bf60b/lib/sqlalchemy/sql/_typing.py)  
> 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](https://github.com/Avaiga/taipy/blob/0877043a9fab3879dc04ff9d188dc7102a830ded/taipy/_run.py#L71)  
> 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](https://github.com/PyGithub/PyGithub/blob/7e7653fb7cb054d3b03dd5f89dea1a2a79350827/github/GithubObject.py)  
> some trivial isinstance + some checking collection elements. 724 should be safe
> 
> - [tfx/tfx/utils/pure\_typing\_utils.py at b4ed9fd64baf5b9e3ae74a3e98e958c29970a050 · tensorflow/tfx · GitHub](https://github.com/tensorflow/tfx/blob/b4ed9fd64baf5b9e3ae74a3e98e958c29970a050/tfx/utils/pure_typing_utils.py#L63)  
> runtime type checking. 724 should be safe
> 
> - [pytorch/torch/serialization.py at cee16353db384dd33a4804f9f26829cacfcfbab7 · pytorch/pytorch · GitHub](https://github.com/pytorch/pytorch/blob/cee16353db384dd33a4804f9f26829cacfcfbab7/torch/serialization.py#L408)  
> trivial isinstance. 724 is safe
> 
> - [core/homeassistant/helpers/service.py at 153c82c2d23b2589a0c68caeaca6947f831eb685 · home-assistant/core · GitHub](https://github.com/home-assistant/core/blob/153c82c2d23b2589a0c68caeaca6947f831eb685/homeassistant/helpers/service.py#L451)  
> 724 is unsafe for entity\_match\_none
> 
> - [airflow/airflow/models/taskinstance.py at 44ba9008870eb63fb244793156da48e91cb17896 · apache/airflow · GitHub](https://github.com/apache/airflow/blob/44ba9008870eb63fb244793156da48e91cb17896/airflow/models/taskinstance.py#L363)  
> 724 is unsafe
> 
> (bonus, since it was mentioned in this thread)
> 
> - [pip/src/pip/\_internal/index/package\_finder.py at main · pypa/pip · GitHub](https://github.com/pypa/pip/blob/main/src/pip/_internal/index/package_finder.py#L946)  
> 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).

---

_[View the full topic](https://discuss.python.org/t/pep-724-stricter-type-guards/34124)._