I'd be curious to hear thoughts from others, but I'd prefer to stick with the assert_type() name. Several of us came up with the same name independently, so it's the most obvious name. While there is some potential for confusion, the function lives in the `typing` namespace, which should make it obvious that it's meant for static typing, not runtime checks.
On 1/23/22 4:39 PM, Jelle Zijlstra wrote:
> https://github.com/python/cpython/pull/30843 is the draft CPython
> implementation. As with the others, any suggestions are welcome. [...]
It occurs to me that users of "assert_type()" - with that function name
- may be surprised that it doesn't actually perform an assertion at
runtime, considering that a regular "assert" statement *does* make a
runtime check. Consider code like:
def parse_int(value) -> int:
assert_type(value, str) # easily read incorrectly as: assert
isinstance(value, str)
return int(value)
I wonder if we might consider a word other than "assert", or maybe add
the word "static" somewhere. Ideas:
* prove_type(value, str)
- Uses the word "prove" instead of "assert"
* static_assert_type(value, str)
- Adds the word "static" in alongside "assert".
JelleZijlstra already did comment:
> That's a reasonable concern, [...]. I'm happy to change the PR if
there's consensus for
> another name. I'll note though that cast() has the same potential
problem, and I
> haven't heard of confusion because of that.
--
David Foster | Seattle, WA, USA
Contributor to TypedDict support for mypy