-
Notifications
You must be signed in to change notification settings - Fork 27
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
Allow supplying np_arrays or list for multi_tags positions #436
Conversation
This pull request introduces 1 alert when merging 41ceed4 into 5275a39 - view on LGTM.com new alerts:
|
Codecov Report
@@ Coverage Diff @@
## master #436 +/- ##
==========================================
+ Coverage 90.41% 90.46% +0.04%
==========================================
Files 55 55
Lines 7087 7118 +31
==========================================
+ Hits 6408 6439 +31
Misses 679 679
Continue to review full report at Codecov.
|
This pull request introduces 1 alert when merging 3d8d938 into e1d56ec - view on LGTM.com new alerts:
|
nixio/multi_tag.py
Outdated
if name in blk.data_arrays: | ||
del blk.data_arrays[name] | ||
pos = blk.create_data_array(name, "{}-positions".format(self.type), | ||
data=da) |
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.
What if da
is an integer or string or some other invalid value? I think it would be confusing for the user if they were trying to create a MultiTag and they got an error about DataArray creation with invalid data. We should catch this issue as early as possible, preferably in the create_multi_tag()
method in the Block
class.
Also, I think this might not be the best location for the convenience functionality to be in general. Having it here makes it possible to create DataArrays by assigning values to mtag.positions
. While this might sound useful, it also makes it more likely that a user tries to do something like:
mtag.positions = [10, 11]
# ... later
mtag.positions = [10, 11, 12]
# or
mtag.positions += [13]
which will lead to all sorts of errors: Duplicate names for the DataArray creation, attempting to append a list to a DataArray, etc.
I think the convenience should only be in the block.create_multi_tag()
method and nowhere else, and it should be documented clearly in the arguments in the docstring. The type check for the positions
argument in create_multi_tag
should check for DataArray
or any kind of sequence
.
nixio/multi_tag.py
Outdated
ext = da | ||
if not isinstance(da, DataArray): | ||
blk = self._parent | ||
name = "{}-extents".format(self.name) | ||
if name in blk.data_arrays: | ||
del blk.data_arrays[name] | ||
ext = blk.create_data_array(name, | ||
"{}-extents".format(self.type) | ||
, data=da) | ||
self._h5group.create_link(ext, "extents") |
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.
Given my comments above about not having the convenience functionality in the positions
setter, I think the same should apply to extents
.
I'm thinking we could have an extents
argument in the create_multi_tag()
method that works the same way as positions
.
In both cases (for positions and extents), I think it only really makes sense to allow the user to automatically create DataArrays for MultiTag positons
and extents
once per MultiTag, on creation. Otherwise, we're creating an incentive for users to create, recreate, and change the positions and extents through these creation functions and that would lead to losing track of DataArray creation, causing naming conflicts and other issues.
nixio/block.py
Outdated
positions = self.create_data_array(da_name, "{}-positions".format(type_), | ||
data=positions) |
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.
positions = self.create_data_array(da_name, "{}-positions".format(type_), | |
data=positions) | |
positions = self.create_data_array(da_name, "{}-positions".format(type_), | |
data=positions) |
nixio/block.py
Outdated
mtag = MultiTag._create_new(self, multi_tags, name, type_, positions) | ||
if not isinstance(positions, DataArray): | ||
da_name = "{}-positions".format(name) | ||
positions = self.create_data_array(da_name, "{}-positions".format(type_), |
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.
Might be good to catch any DA creation exceptions here, specifically any exception that will be thrown if the positions
data is invalid. We could then re-raise it from here with a more appropriate message that mentions the MultiTag positions array explicitly.
nixio/block.py
Outdated
extents = self.create_data_array(da_name, | ||
"{}-extents".format(type_) | ||
, data=extents) |
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.
extents = self.create_data_array(da_name, | |
"{}-extents".format(type_) | |
, data=extents) | |
extents = self.create_data_array(da_name, | |
"{}-extents".format(type_), | |
data=extents) |
See also above comment about the DataArray creation exceptions.
nixio/block.py
Outdated
extents = self.create_data_array(da_name, | ||
"{}-extents".format(type_) | ||
, data=extents) | ||
mtag = MultiTag._create_new(self, multi_tags, name, type_, positions, extents) |
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.
Don't change the MultiTag._create_new()
method. Just add extents to the mtag after it's created.
This pull request fixes 1 alert when merging 61fdde0 into ff5c813 - view on LGTM.com fixed alerts:
|
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.
Error handling changes discussed.
This pull request fixes 1 alert when merging 43019f0 into ff5c813 - view on LGTM.com fixed alerts:
|
Looks good. I'd like to see some more extensive tests. Like having invalid positions (not just Let me know if you want to include them here. Otherwise rebase and I'll merge. |
Ok, then don't merge now. I will include them here |
This pull request fixes 1 alert when merging 63787ad into 6d0b2f3 - view on LGTM.com fixed alerts:
|
This pull request fixes 1 alert when merging a250bd6 into 6d0b2f3 - view on LGTM.com fixed alerts:
|
Also for extents.
Referring to #418, #789.
Also add some test for this constructor.