[Typing-sig] Re: Proposal: typing.assert_type() and with typing.assert_error()

On the contrary, pytype added `assert_type` because users came up with the idea and asked for it, as a way to make sure the typechecker was doing what they expected it to. Since the notion of python static typing is closely tied to the operation of the type checker, I would say `assert_type` is fine being in typing. martin On Wed, Feb 9, 2022 at 1:25 AM Никита Соболев wrote:

I had some time to think about this problem, since it affects multiple mine projects.

In my opinion this should not go into `typing` at all. As I see it, `typing` is for typing utilities that are useful for a wide range of users.

But, `assert_type` is only useful for maintainers of type-checkers and typed libraries (very small percent). With some *very limited* usage in the end code.

Maybe we can create a special package under https://github.com/python/typing and call it something like `advanced_type_utils`?

I see several pros: - It will be independent from CPython's release cycle - It will still be "official" - We can add more "advanced" features there without the fear that they might be misinterpreted by a wider range of users - We can still standardize it across type-checkers, the same way we do it for `typing_extensions`

Cons? - Harder visibility (It might be a plus as well, depending on the interpretation) - Extra dev-only dependency for libraries to test their types (I think we can live with that) - Possible complexity to support multiple Python versions (I am probably overthinking it)

Do others agree? :)

Best, Nikita Sobolev

ср, 9 февр. 2022 г. в 10:25, Shantanu Jain :

...

I'm also a little bit worried about confusion stemming from "assert" in the name. For instance, note that the recently added `assert_never` does actually perform an assert at runtime. I don't think `cast` really suffers from the same problem, since it doesn't have "assert" in the name. Recently there's been a bunch of discussion about the lines between runtime typing and static typing and I think it behooves us to try to avoid creating points of potential confusion.

I liked the suggestion of `static_assert_type`. Another suggestion would be `check_type`.

On Sun, 6 Feb 2022 at 16:08, Guido van Rossum wrote:

...

I for one have been confused by the usage of the term "assert" for this. In particular it took me a long time to be convinced that this has any value over just writing "assert False". So I think we should maybe take a step back and think hard about this.

On Sun, Feb 6, 2022 at 3:32 PM Jelle Zijlstra wrote:

...

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.

El jue, 3 feb 2022 a las 7:51, David Foster () escribió:

...

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".

...

That's a reasonable concern, [...]. I'm happy to change the PR if

...

another name. I'll note though that cast() has the same potential

JelleZijlstra already did comment: there's consensus for problem, and I

...

haven't heard of confusion because of that.

-- 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: guido@python.org

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c... _______________________________________________ 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: hauntsaninja@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: n.a.sobolev@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: mdemello@google.com