no error when sentinel name does not match variable name

[DetachHead]

Summary

foo = sentinel('bar') # no error

Playground

see https://peps.python.org/pep-0661/#typing

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

Version

986ea67d6

[carljm]

Thanks! PR attached that will fix this.

[carljm]

Hmm, on second look, python/typing#2277 proposes to remove this text when adding this PEP to the spec and conformance suite. Until that is resolved, I think we should hold off on adding this. Going to mark the attached PR as draft for now.

[DetachHead]

quoting that PR:

It may be a good code quality rule to require that the two names match, but type checkers should be able to support sentinels in annotations fine even if they don't match.

perhaps it makes sense to move this issue to ruff then?

[carljm]

I guess it could also be an opt-in rule for ty? Ty can be a bit more accurate in verifying the RHS is really constructing a sentinel-- though probably doesn't practically matter.

[AlexWaygood]

Note that our existing rule for typeddicts/namedtuples/newtypes etc is already only a warning by default, since from ty's perspective enforcing this isn't required for correctness, so it's just a lint.

I think the situation may be different for other type checkers, which recognise these constructor calls using more syntactic checks, so really do need the passed-in name to match. I'm not totally sure about that, though

[AlexWaygood]

Ty can be a bit more accurate in verifying the RHS is really constructing a sentinel

(You could make that argument about 90% of ruff rules in some form, I think, but in practice ruff is "accurate enough" here that this comes up exceedingly rarely in user issues. So i don't find this point in itself particularly persuasive. I find it more persuasive that we already emit this lint for various other type constructors, and for us it's always a stylistic rule, and so it's a bit weird to say that this one specifically has to go in Ruff rather than ty. Perhaps the typing spec should say that type checkers "may" emit an error for this, but that it is not mandated, if it is agreed that it is generally good coding style to do this.)

[carljm]

The spec PR has now landed, so my draft attached here should not land as-is; we should either close it, or update it to use a separate error code and be disabled by default.