Uh oh!
There was an error while loading. Please reload this page.
clarify Final reassignment semantics - #2241
Conversation
carljm
left a comment
There was a problem hiding this comment.
I think this is a superior rule, but I would be likely to think so, since it's the rule ty already implements 😆
I think this PR needs some improvements, but I'm in favor of the change.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
db50e16 to
790786bCompare790786b to
d51cf3dCompare| else: | ||
| ID3 = 2 # OK | ||
| ID4: Final[int] # E: not exhaustive assignment |
There was a problem hiding this comment.
I'm not sure I agree that it should be required to enforce exhaustive assignment. Why should this be enforced for a Final name, but not for other names?
There was a problem hiding this comment.
i would expect a type checker to enforce this for all names. but this change is only regarding Final, which to me is even more "static" than normal variables, that a Final name without a value should always be impossible
https://discuss.python.org/t/clarify-final-assignment/106878