FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Add error code for mutable covariant override by ilevkivskyi · Pull Request #16399 · python/mypy · GitHub

Repository navigation

Add error code for mutable covariant override - #16399

Merged
ilevkivskyi merged 4 commits into
python:masterfrom
ilevkivskyi:mutable-override
Nov 9, 2023
Merged

ilevkivskyi merged 4 commits into
python:masterfrom
ilevkivskyi:mutable-override

Conversation

Copy link
Copy Markdown
Member

Fixes #3208

Interestingly, we already prohibit this when the override is a mutable property (goes through FuncDef-related code), and in multiple inheritance. The logic there is not very principled, but I just left a TODO instead of extending the scope of this PR.

hauntsaninja left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

We should accept:

class X:
    x: float

class Y(X):
    x = 5

When I made this same patch I did this by only doing the check if lvalue_type

This comment has been minimized.

Copy link
Copy Markdown
Collaborator

Also #3208 (comment) is similar hole, might be worth opening separate issue for it

Copy link
Copy Markdown
Member Author

@hauntsaninja

We should accept:

Why should we allow this? x = 5 at class scope creates a new Var symbol (you can check that y: Y; reveal_type(y.x) will show an int), so it causes exactly the same unsafety (and also changing inference logic depending on an error code is a bad idea). The rules for whether we create a new Var or assign to the superclass' Var are these:

  • If there is an annotation, always create a new Var (for both x: int and self.x: int)
  • If there is no annotation, self.x = ... re-uses existing Var, but x = ... creates a new Var

You may be tempted to change these rules, but believe me they are very old, and may break some unexpected things (especially in the daemon). Or did you mean we should allow self.x = 5? This should be already allowed (for exactly the rules I listed above, since there is just one Var, there is nothing to compare with in superclass). Btw, this is a very good thing to test.

Also #3208 (comment) is similar hole, might be worth opening separate issue for it

Yes, this is a separate story, and there are problems not just for variables, but for methods as well.

github-actions Bot commented Nov 4, 2023

Copy link
Copy Markdown
Contributor

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

hauntsaninja left a comment •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Ah, I didn't realise x = 5 and self.x = 5 were different. Thanks for adding the test!

Then yes, this looks good to me! Note that if we ever want to turn this code on by default, we should consider the change... IIRC fixed several mypy_primer hits when I tried out my diff

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reject covariant overriding of attributes

2 participants


Back | FazBrowse Home | New Git URL