-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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 and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DatasetView class breaks Liskov's rule. #8855
Comments
Thanks for opening your first issue here at xarray! Be sure to follow the issue template! |
This seems like it should be resolvable... But if we can satisfy mypy with some ignores we should definitely do that in the short term, we have much more interesting parts of datatree to get to, and we can always come back to this without making breaking changes. |
I think the right way to fix this from a typing perspective would be to make |
Would that work though? It would mean that EDIT: But maybe that just isn't something we should be trying to make work. |
Indeed, I think the situation is similar to Python's Another option for us could be to add an |
What is your issue?
Working on migrating the datatree.py module into
xarray/core
revealed that theDatasetView
class, which implementsDataset
while disabling methods to mutate the object, breaks Liskov's substitution principle. The type for one of the overloads ofDatasetView.__getitem__
is more general than the correspondingDataset.__getitem__
signature (due to the use ofSelf
in the Dataset signature).The use of
Self
means that signature inherited from the superclass has a return type ofDatasetView
, but theDatasetView
signature is overridden to have a return type ofDataset
(the more generalised parent).To avoid this, a couple of implementations were attempted:
Dataset
usinggetattr
. This does not catch the__setitem__
method, as it is a Magic Method, and those aren't affected bygetattr
.Metaclass
that can intercept Magic Methods, too. Implementation was inspired from here. I didn't get it to fully work, and eventually realised this was getting too complicated given the scope of the original problem.mypy
errors for now, so we can proceed with the migration (given that there isn't a significant implementation concern identified from these type issues).Also note, there is a tangentially-related known
mypy
error when a property setter accepts an argument of a different type to the property itself (python/mypy#3004). This affects the assignment ofDataset
objects to theDataTree.ds
property. (Separate issue, but related)The text was updated successfully, but these errors were encountered: