# PEP 724: Stricter Type Guards **URL:** \ **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:** 60
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [September 23, 2023, 8:24am UTC](https://discuss.python.org/t/pep-724-stricter-type-guards/34124/60 "2023-09-23T08:24:13Z")
> [@mdrissi](#): > > Edit 2: It would be nice if using this peps semantics isinstance(obj, Foo) and using function with TypeGuard[Foo] had same behavior. I think that are some soundness holes but pragmatically making exact same behavior is simpler to explain then saying new behavior narrows both positive and negative but rules still may differ in subtle ways between normal isinstance vs user defined type guard. This seems like a reasonable idea, and suggests `IsInstance[T]` for the type name. Even if there are subtle differences, maybe documenting them under a note explaining why the semantics can’t be exactly the same would be enough. For me, the two names would then make sense - `TypeGuard` - asserts that a value is of a given type, but says nothing when it can’t make that assertion. - `IsInstance` - confirms if a value is _or is not_ of a given type. “Guard” has the sense of a one-sided check, where “is” feels two-sided to me. On a more general note, it would be nice if cases like `isinstance`, where type checkers special-case particular builtins and stdlib names (I believe `dataclass` is another one) we’re listed somewhere and documented. At the moment they tend to come up in discussions as unverified presumptions, which is not ideal. --- _[View the full topic](https://discuss.python.org/t/pep-724-stricter-type-guards/34124)._