Fix incorrect truthyness for Enum types and literals by Daverball · Pull Request #17337 · python/mypy (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation20 Commits16 Checks18 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

Daverball

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.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@Daverball

This comment was marked as resolved.

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

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?

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

This comment has been minimized.

@Daverball

@github-actions GitHub Actions

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

hauntsaninja

Choose a reason for hiding this comment

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

Nice, thank you!

Re your comment: I think most attribute lookups should go through analyze_member_access

2 participants

@Daverball @hauntsaninja