`invalid-sentinel` - why does the argument have to be a literal?

[DetachHead]

https://pyrefly.org/en/docs/error-kinds/#invalid-sentinel

# First argument passed to sentinel constructor isn't a string literal
my_str: str = "MISSING"
A = Sentinel(my_str)

this requirement doesn't seem to be mentioned in the docs or the PEP, but interestingly pyright also reports the same error. (ty doesn't)

i'm wondering if theres some documentation somewhere i'm missing, or if this just came from an early draft of the PEP that was later removed?

[yangdanny97]

I don't think it's a hard constraint, but we can't validate that the variable has the same name as the sentinel if we don't know the name statically

[DetachHead]

ah, i must've missed this part of the PEP:

If the name passed to sentinel() does not match the name the object is assigned to, type checkers should emit an error.

ideally the type checker shouldn't have special-case an error when the argument isn't a LiteralString though. that's typeshed's job. see these PRs:

• use LiteralString for sentinel name python/typeshed#16094
• use LiteralString for Sentinel name python/typing_extensions#783

[DetachHead]

I don't think it's a hard constraint, but we can't validate that the variable has the same name as the sentinel if we don't know the name statically

looks like pyrefly currently doesn't do that:

foo = sentinel("bar") # no error

sandbox

[AlexWaygood]

I don't think it's a hard constraint, but we can't validate that the variable has the same name as the sentinel if we don't know the name statically

Note that python/typing#2277 proposes to remove this text when adding this PEP to the spec and conformance suite.

[rchen152]

I took a quick look, and pyrefly already falls back to the assigned name when sentinel gets a non-literal argument, so I think we can relax this restriction. The discussion on the conformance test is ongoing, but in the current state, we don't need to check that the names match. We can add this error back if that changes.