You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support properties with setter type different from getter type (python#18510)
Fixespython#3004Fixespython#11892Fixespython#12892Fixespython#14301
_Note:_ this PR should be reviewed with "hide whitespace" option (in
couple long functions I replace huge `if x: ...` with `if not x: return;
...` to reduce indent level).
The core logic is quite straightforward (almost trivial). The only
couple things are:
* We should be careful with binder (we simpy can't use it for properties
with setter type different from getter type, since we don't know
underlying property implementation)
* We need to handle gracefully existing settable properties that are
generated by plugins
The tricky part is subclassing and protocols. The summary is as
following:
* For protocols I simply implement everything the "correct way", i.e.
for settable attributes (whether it is a variable or a settable
property) compare getter types covariantly and setter types
contravariantly. The tricky part here is generating meaningful error
messages that are also not too verbose.
* For subclassing I cannot simply do the same, because there is a flag
about covariant mutable override, that is off by default. So instead
what I do is if either subclass node, or superclass node is a "custom
property" (i.e. a property with setter type different from getter type),
then I use the "correct way", otherwise the old logic (i.e. flag
dependent check) is used.
Two things that are not implemented are multiple inheritance, and new
generic syntax (inferred variance). In these cases setter types are
simply ignored. There is nothing conceptually difficult about these, I
simply run out of steam (and the PR is getting big). I left `TODO`s in
code for these. In most cases these will generate false negatives (and
they are already kind of corner cases) so I think it is OK to postpone
these indefinitely.
0 commit comments