Possible regression in enum member literals as sentinel values

[Sharp-Eyes]

A pattern I've seen somewhat often (for example in attrs) and have adopted myself in a couple projects is declaring sentinel values as follows:

import enum
import typing


class _Sentinel(enum.Enum):
    SENTINEL = enum.auto()


SENTINEL = _Sentinel.SENTINEL


def foo(x: int | None | typing.Literal[SENTINEL] = SENTINEL):
    ...

where the line with Literal[SENTINEL] throws

Variable not allowed in type expression Pylance(reportInvalidTypeForm)
Type arguments for "Literal" must be None, a literal value (int, bool, str, or bytes), or an enum value Pylance(reportInvalidTypeForm)

I am aware that this can still be achieved by changing the annotation to

def foo(x: int | None | _Sentinel = SENTINEL):
    ...

# OR

def foo(x: int | None | typing.Literal[_Sentinel.SENTINEL] = SENTINEL):
    ...

However, with attrs as an example, this would lead to accessing attr._make._Nothing, which is still somewhat undesirable.

My "question" therefore is whether or not the typing errors raised in the first codeblock are intentional.

I haven't had time to figure out exactly which pyright update caused this to raise, but I'm certain it worked on pyright version 1.1.366.
After some testing, it appears that this started happening on pyright version 1.1.371.

[erictraut]

Yes, this error is intentional. This behavior is mandated by the Python typing spec, which explicitly disallows variables from being used in type expressions, including Literal type definitions.

Your code sample is conflating value expressions with type expressions. The statement SENTINEL = _Sentinel.SENTINEL defines a variable whose type is initialized to the value _Sentinel.SENTINEL. By contrast, the statements type SENTINEL = Literal[_Sentinel.SENTINEL] and SENTINEL: TypeAlias = Literal[_Sentinel.SENTINEL] define a type alias whose type is a literal.

[Sharp-Eyes]

Clear as day, thank you. In the meantime, I'll see if I can get this updated on attrs' end.