+1

Are there any existing provisions in type checking tools to denote that a type hint of n should be interpreted as type(n) — basically the case of a singleton?

The obvious case is None → type(None). I wonder if there would a more general case beyond sentinel to be supported here.

Paul 

On Tue, 2021-06-08 at 17:54 +0200, Sebastian Rittau wrote:

Am 08.06.21 um 17:44 schrieb Jelle Zijlstra:

Looking at your PEP, I think it would be more user-friendly if the sentinel can be used directly as a type annotation, something like this:

SENTINEL = sentinel("SENTINEL")

def print_exception(*, value=Exception | SENTINEL) -> None: ...

This would be similar to how None works, and it would make the type annotation more concise than when we use Literal.

+1

2. What should the process be, in terms of what the PEP defines and what is later implemented in mypy and similar tools?

My preference would be that the PEP specifies how this new feature interacts with typing, either by allowing sentinels as types directly (my proposal above) or by saying that PEP 586 is amended to allow sentinels in Literal.

+1

Sorry for just +1'ing, but Jelle formulated the thoughts I had. Type checkers will need to special case sentinels anyway, so using Literal[] seems to be just unnecessary noise.

 - Sebastian

_______________________________________________

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: pbryan@anode.ca

_______________________________________________
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