python
Fix incorrect truthyness for Enum types and literals
Fixes: #17333
This ensures can_be_true and can_be_false on enum literals depends on the specific Enum fallback type behind the Literal, since __bool__ can be overriden like on any other type.
Additionally typeops true_only and false_only now respect the metaclass when looking up the return values of __bool__ and __len__, which ensures that a default Enum that doesn't override __bool__ is still considered always truthy.
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I'm not thrilled about the number of [builtins fixtures/tuple.pyi] I've had to add just so that Literal[True] in enum.pyi works. Maybe it would be better to use union.pyi or define a separate literal.pyi that's even more minimal than union.pyi for now.
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
BTW I found it a little concerning that TypeInfo.get and TypeInfo.get_method only consider the mro and not the metaclass when looking up symbols, but I didn't have the stomach to change this, since there probably is code that depends on this behavior.
I fear however that there are quite a few more places where attribute lookups are incorrect (other than the one I have fixed in this PR), because the attribute is defined on the metaclass and not on the class itself. Should we perhaps create an issue to potentially review call sites of get/clean this up/improve documentation to avoid more errors in the future?
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
@hauntsaninja Not asking for a review (although that would be nice too), but for your thoughts on my comment above: https://github.com/python/mypy/pull/17337#issuecomment-2175328305
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅