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/EMUD2D424OI53DCWQ4H5L6SJD2IXBHUL/)
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
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: ikamenshchikov@gmail.com