Skip to content

feat(typing): Enable mypy strict_equality in our strongly typed config#108606

Merged
kcons merged 5 commits intomasterfrom
kcons/stricteq
Feb 23, 2026
Merged

feat(typing): Enable mypy strict_equality in our strongly typed config#108606
kcons merged 5 commits intomasterfrom
kcons/stricteq

Conversation

@kcons
Copy link
Member

@kcons kcons commented Feb 19, 2026

strict_equality occasionally seems a bit picky, but it flags nonsense comparisons that can be tricky to identify otherwise.
On average, it seems to make us safer and more honest without too much cost, and this in turn makes us able to move faster.

See also:

@kcons kcons requested review from a team as code owners February 19, 2026 22:30
@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Feb 19, 2026
@kcons kcons requested a review from a team February 19, 2026 23:43
assert GrantCacheStatus.NEGATIVE_CACHE == "negative_cache"
assert GrantCacheStatus.VALID_WINDOW == "valid_window"
assert GrantCacheStatus.EXPIRED_WINDOW == "expired_window"
assert GrantCacheStatus.CACHE_MISS.value == "cache_miss"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unrelated to this PR, but curious about python enums and .value notation.

My understanding was that this is specifically meant to be for the default enums, and IntEnum / StrEnum could be accessed safely w/o .value?

(maybe this is just one of the python-isms i can't get used to, why do you need the .value when it already has the key?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good thing to flag. This is, depending who you ask, a mypy bug or a Python typing spec bug.
I've seen https://discuss.python.org/t/amend-pep-586-to-make-enum-values-subtypes-of-literal/59456/9, python/mypy#16327, and a few others.

But, I believe this issue is limited to subclass enum to literal comparisons, which should be rare in practice (as the enum is intended to take the role of a literal).
So, as I understand it, a niche case with a fairly straightforward workaround (.value) that will probably go away or can be made to go away.

(I did look into updating our mypy plugin to fix these, but it wasn't trivial and didn't seem worth it)

@kcons kcons enabled auto-merge (squash) February 23, 2026 18:26
@kcons kcons merged commit 628e504 into master Feb 23, 2026
102 checks passed
@kcons kcons deleted the kcons/stricteq branch February 23, 2026 18:43
mchen-sentry pushed a commit that referenced this pull request Feb 24, 2026
#108606)

strict_equality occasionally seems a bit picky, but it flags nonsense
comparisons that can be tricky to identify otherwise.
On average, it seems to make us safer and more honest without too much
cost, and this in turn makes us able to move faster.

See also:
 * #108478
 * #108466
 * #108462
 * #108450
 * #108448
 * #108578
@github-actions github-actions bot locked and limited conversation to collaborators Mar 11, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants