-
Notifications
You must be signed in to change notification settings - Fork 300
Ensure cubelists only contain cubes #3238
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
Closed
Closed
Changes from 1 commit
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
4ab7cfa
ensure cubelists only contain cubes
rcomer 0b293ec
address __iadd__ and __setitem__
rcomer 8a74df9
__setitem__ tests
rcomer 2622254
test for setting more than 1 item
rcomer 39d5f4d
Fix __setitem__ and Py2 tweaks
rcomer 4187162
implement __setslice__ for Python2.7
rcomer 569f35e
change exceptions to warnings
rcomer 5b13dcc
stickler
rcomer 8f272fb
duck type check; move helpers outside class
rcomer f7134c1
blank lines
rcomer bc7eb7a
proposed: revert warnings to exceptions
rcomer d961a68
remove stray extra 'test_fail'
rcomer a84823e
Merge branch 'master' of github.com:SciTools/iris into cubelist-conta…
rcomer 7fe5d0a
pass sequences through __init__; _assert_is_cube
rcomer File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Style question: Is this the right place for these checking functions, or should they be defined outside the class?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My take : these don't use instance properties, so they could be static methods.
... They don't use any class properties either, so they don't really need to be in the class at all.
In fact, they don't use private properties of Cube, so they don't really need to be in the module.
At that point (they are just functions), they could go somewhere else.
However, for personal preference, I'd remove them from the class but keep them as private methods in cube.py, just in case they might need to use 'private' cube concepts in future.
Also ... the use of
isinstanceprevents any duck typing (lookalike objects can't masquerade as Cubes), which is arguably un-Pythonic.We have previously used
hasattr('add_aux_coord')for this elsewhereThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so if we check whether the object quacks with an auxcoord instead of checking the type, is there any reason not to revert to raising an exception rather than a warning?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh dear, I had somehow skimmed over that latest discussion without taking it in.
Now I see that @pelson and I are just advocating different approaches, and I honestly don't know how to choose between.
Personally though, I must say I do hate all the warnings in Iris. There are still far too many, most occurrences are a pointless nuisance, and on the rare occasions when they aren't no-one is listening any more.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem: I'm partly using this as a learning exercise, so exploring different solutions to the same issue is fine 👍
I think I prefer to have an exception on the grounds that, if my code is going to fail, it's better for it to fail sooner rather than later. Also, having the failure at the point that the object is included into the cubelist means that the traceback is going to point me a lot closer to where I made the mistake. Which so far has always been
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nicely done! 😆
As a user, I'd still rather have an exception if possible, for the reasons I gave above.
If something does go wrong with my cubelist, the first thing I'm going to do in an attempt to debug is print it. So if we're looking for a minimal set of cube-like attributes,
summaryought to be up there.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we thinking about this the wrong way round? Rather than trying to define which types should be allowed in a cubelist, it might be easier to focus on which types should definitely be rejected.
This started because a rogue
Nonein a cubelist caused problems, and I wanted a more informative error message. So far I’m not aware of any other types that have caused issues. So my case would be solved by simply throwing an exceptionif object is None. We could generalise that a bit if we decide that, at minimum, the cubelist should be printable, so reject any objects that don’t have have asummaryattribute.The exception message needn’t say anything about how similar to a
Cubethe object is, but could just say ”object of type [whichever] does not belong in a cubelist”.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so in this case. Because users can create and use their own CubeList instances, the minimum set of behaviour required for an entry into a CubeList is precisely the Cube's behaviour (and no less).
Useful to know, thank you. So my biggest concern is that we are essentially introducing a breaking change if we do this as an exception - if @rcomer has been adding
Noneinto a cube list by accident, just think of all the wild things that some of our less educated users have been doing! 😭I guess there is a workaround though... if users really want to do this they can still do
list.append(cube_list_instance, thing_that_isnt_a_cube)until they sort their 💩 out.In an attempt to get consensus and prevent this conversation from being open-ended, my refined suggestion:
CubeList._assert_is_iterable_of_cubes-> just construct a CubeList of the subset - that way you can honour iterators, and then add the constructed CubeList as necessary.CubeList.__new__to use_assert_is_cube.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hadn't considered the possibility of cubelists being used to store random types 😮 . Semi-serious question: how far away is Iris 3?
Just to check I've understood: we make it strict so only
Cubeinstances are allowed. Because the check is restricted to one method, someone who wants to include ducks in the cubelist just needs to replace that one method?Points 1 and 2 sound good to me.
Point 3: I think I need to wait for #3264 to be merged, and then update
__init__!Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if it helps, but..
In my mind, even if it was previously possible to put non-cubes into a CubeList, that was never intended behaviour -- evidence the code covered by #3264.
So that is a bug, and fixing a bug is not a "breaking" change.
Weaselly, but we've accepted that principle before.