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 Никита Соболев <n.a.sobolev@gmail.com> 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 <hauntsaninja@gmail.com>:
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 <guido@python.org> 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 <jelle.zijlstra@gmail.com> 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 (<davidfstr@gmail.com>) 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".


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
_______________________________________________
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)
_______________________________________________
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