
El mar, 1 feb 2022 a las 22:05, David Foster (<davidfstr@gmail.com>) escribió:
In a previous typing-sig thread ( https://mail.python.org/archives/list/typing-sig@python.org/thread/EMUD2D424...)
there was a discussion about the existing TypeGuard (PEP 647) and the desire to support a form that allows for type narrowing in the negative case.
I agree that supporting a negative case would be useful. I generally like the initial specification for StrictTypeGuard:
The type checker would enforce the requirement that the type guard type (specified as a return type of the type guard function) is a subtype of the input type (the declared type of the first parameter to the type guard function). In other words, the type guard type must be strictly narrower than the input type.
-0. This restriction feels a bit arbitrary to me. Does it potentially allow for better typechecker error messages or a simplified typechecker checking implementation?
Type narrowing would be applied in the negative ("else") case. This may still lead to incorrect assumptions, but it's less likely to be incorrect with restriction 1 in place.
+1. Great. Avoids the need to introduce something like `Not[T]`, as in `TypeGuard[Not[T]]`.
If the return type of the type guard function includes a union, the type checker would apply additional type narrowing based on the type of the argument passed to the type guard call, eliminating union elements that are impossible given the argument type.
+0. Not sure how useful this is, considering that the specific example with Literals isn't similar to any code I've written in the last few years. But the behavior certainly makes sense.
We'd need to come up with a new name for this, perhaps StrictTypeGuard, ExactTypeGuard, or PreciseTypeGuard. Other suggestions are welcome.
Perhaps `TypeGuard[T, strict=True]` would be a possible spelling? I seem to vaguely recall that the ability to add kwargs to brackets like [] was added to legal syntax.
This was proposed in PEP 637 but rejected.
I am lukewarm RE the introduction of either TypeAssert or StaticTypeAssert. You can rewrite imperative "assert" functions of the type in the examples as functional "parse" functions with existing type annotations:
Instead of:
def assert_is_one_dimensional(val: tuple[T, ...] | T) -> StrictTypeAssert[tuple[T] | T]: if isinstance(val, tuple) and len(val) != 1: raise ValueError()
You could write:
def parse_one_dimensional(val: tuple[T, ...] | T) -> Optional[tuple[T] | T]: if isinstance(val, tuple) and len(val) != 1: return None else: return val
-- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com