+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

On Tue, Jun 8, 2021 at 8:54 AM Sebastian Rittau <srittau@rittau.biz> 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.

Why do type checkers have to special-case sentinels? Until this idiom has become popular, using `Literal[SENTINEL]` seems the most logical approach. The only change to type checkers in that case would be to treat `sentinel` as one of the types whose values can be used in `Literal[]`. (More generally speaking, allowing all values to be used directly instead of literals would of course be nice, but the current use of strings for forward references pretty much blocks that; I'm not sure we should start making individual exceptions for sentinels.) -- --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-change-the-world/>

On Tue, 2021-06-08 at 20:40 +0200, Sebastian Rittau wrote:

Unless I misunderstand something (quite possible!), the following idiom does not currently work with type checkers and is not supposed to work:     X = foo()     def bar(x: Literal[X]) -> None: ... This means that "X = sentinel()" would need to be special-cased.

Why can't a sentinel class itself be used? Why would it need to be instantiated? Paul

I suppose I'm hoping for some variant of the Use class objects rejected idea from the PEP: define your own specific sentinel class, which subclasses a Sentinel base class, or has a Sentinel metaclass.  The base class would be responsible for providing the __repr__ and __str__ implementations. Then, one uses the specific subclass as the sentinel, and it can be easily type checked. So, ideally, something like: class MySentinel(Sentinel):     pass Paul On Tue, 2021-06-08 at 21:02 +0200, Sebastian Rittau wrote:

Am 08.06.21 um 20:54 schrieb Paul Bryan:

...

On Tue, 2021-06-08 at 20:40 +0200, Sebastian Rittau wrote:

...

Unless I misunderstand something (quite possible!), the following idiom does not currently work with type checkers and is not supposed to work:     X = foo()     def bar(x: Literal[X]) -> None: ... This means that "X = sentinel()" would need to be special-cased.

Why can't a sentinel class itself be used? Why would it need to be instantiated?

Do you mean something like this?     # sentinels.pyi

    class Sentinel: ...  # this is currently not part of the PEP and wouldn't exist at runtime     def sentinel(...) -> Sentinel: ...     # foo.py

    X = sentinel()     def bar(x: X) -> None: ... Apart from the part that a "Sentinel" class currently isn't part of the PEP (although I'd prefer if it was), this means that all sentinels would be type compatible with each other and using the wrong sentinel wouldn't be caught at type checking time. If this is not what you meant, could you give an example?  - 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

On Tue, Jun 8, 2021 at 11:40 AM Sebastian Rittau <srittau@rittau.biz> wrote:

Am 08.06.21 um 18:51 schrieb Guido van Rossum:

Why do type checkers have to special-case sentinels? Until this idiom has become popular, using `Literal[SENTINEL]` seems the most logical approach. The only change to type checkers in that case would be to treat `sentinel` as one of the types whose values can be used in `Literal[]`.

Unless I misunderstand something (quite possible!), the following idiom does not currently work with type checkers and is not supposed to work:

X = foo() def bar(x: Literal[X]) -> None: ...

This means that "X = sentinel()" would need to be special-cased.

Hm, I think you're right. I was thinking of X = 42 def bar(x: Literal[X]): ... but I don't even know if that works, and even if it did, it wouldn't work if you replaced 42 with a call to int(...). -- --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-change-the-world/>

On Tue, Jun 8, 2021 at 11:19 PM Tal Einat <taleinat@gmail.com> wrote:

On Tue, Jun 8, 2021 at 11:09 PM Guido van Rossum <guido@python.org> wrote:

...

On Tue, Jun 8, 2021 at 11:40 AM Sebastian Rittau <srittau@rittau.biz> wrote:

...

Am 08.06.21 um 18:51 schrieb Guido van Rossum:

Why do type checkers have to special-case sentinels? Until this idiom has become popular, using `Literal[SENTINEL]` seems the most logical approach. The only change to type checkers in that case would be to treat `sentinel` as one of the types whose values can be used in `Literal[]`.

Unless I misunderstand something (quite possible!), the following idiom does not currently work with type checkers and is not supposed to work:

X = foo() def bar(x: Literal[X]) -> None: ...

This means that "X = sentinel()" would need to be special-cased.

Hm, I think you're right. I was thinking of

X = 42

def bar(x: Literal[X]): ...

but I don't even know if that works, and even if it did, it wouldn't work if you replaced 42 with a call to int(...).

The precedent here is Enum values. How does Literal work with Enum values? Could sentinels use the same mechanism?

Enums have a considerable amount of special-casing, both at runtime and in static checkers. Basically, when comparing Color.RED and Color.BLUE, the static checker knows that these are not the same value. (With the exception of aliases, I'm not sure how those work.) But when you compare Color(x) and Color.RED, the checker doesn't have enough information to tell whether they are the same, and will always give you an error. (The same as when you take a value of type int and try to match it against Literal[42].) Without special-casing the static checker wouldn't know whether X and Y could be the same or not if you write X = sentinel() Y = sentinel() and it also wouldn't know that X cannot be changed to a different value. Maybe it could be made to work if you write X: Final = sentinel() but this would require an extension of the concept of Literal[], which, as currently defined, only supports a few types (IIRC bool, int, str, and enums). I think it doesn't even support aliases, so X: Final = 42 does not make X compatible with Literal[42] (though I'm not sure of that). (Can you tell I'm not set up to try anything out? Nor do I feel like re-reading the PEP... :-) -- --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-change-the-world/>

Am 09.06.21 um 09:04 schrieb Tal Einat:

The more I think about it, the more I'm inclined to find an implementation that would require no special support from type checkers. That is, an implementation which would allow existing type analysis to "just work". But it seems that would be impossible with an interface of the form currently suggested in the PEP, `NotGiven = sentinel('NotGiven').`

I honestly think that requiring type checkers to special case this is fine. All implementations that would work with the existing type system are a bit awkward to use. In my opinion the type system should serve the language, but the language shouldn't be constrained by it. (Although often when something doesn't work within the type system, it's an indication that it might not be the best/clearest solution. Sentinels are special enough to earn special treatment.) The only thing that I think would help the typing case is having a Sentinel base class as I mentioned in the discuss thread. This allows us to write functions that accept arbitrary sentinels (for whatever reason) in a type-safe manner.  - Sebastian

If the singleton pattern of PEP 484 is too cumbersome, why not update [PEP 586](https://www.python.org/dev/peps/pep-0586/#legal-and-illegal-parameterization...) (which defines `Literal` type) to extend the legal parameterization by adding `object` variable declared as `Final` ? (Because `object` instances are immutable, so they meet the `Literal` criteria when they are also declared as `Final`) My previous example could be written: ```python from typing import Final, Literal, Union empty: Final = object() def func(x: Union[int, Literal[empty]]) -> int: return 0 if x is empty else x ``` This would be a quite simple and elegant solution, which doesn't require any additional stuff too. The enum singleton pattern could still be used when more customization (magic method overriding) is needed.