-
Notifications
You must be signed in to change notification settings - Fork 13
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
Implement BidsPartialComponent
#284
Implement BidsPartialComponent
#284
Conversation
8756d18
to
f9f74ad
Compare
581f837
to
f908a54
Compare
Okay, I think that finally fixes all the test failures. Just note for posterity, when combining |
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.
The code basically looks good to me, just a few changes for the docstrings (some of which are a matter of opinion and optional)
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.
A couple of spelling things found, but pending resolution of Tristan's review, think this one may be good to go.
Re: your design question - what would be the alternative?
Not sure, guess I wanted to see if either of you would object to the status quo |
Sorry, forgot to specifically address this as part of my first review. I'd also be happy with |
Okay, I'm just going to keep it then. |
247a99b
to
1067740
Compare
I implemented the requested changes and the
|
1067740
to
0858f9a
Compare
0858f9a
to
23c5c6b
Compare
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.
lgtm pending merge conflict fix
23c5c6b
to
2b18a0f
Compare
2b18a0f
to
b019748
Compare
Note that we don't use importlib_resources, as it caused problems on github actions
Copies all the methods from tuple, including hashable (which only works if all of the contents are hashable). Does not support mutation
Represents the expand(), filter(), and zip_lists attributes
A generic interface supporting a key type, a value type for single keys, and a seperate value type for tuple keys
The new BidsComponent only contains code relevant to the name and path Change constructor arguments of both classes into keyword-only, as the order of the arguments changed anyway, and kw_only increases future clarity and robustness
Represents a single selected entity from a BidsComponent. Implemented as an Immutable list, so supports all the methods and abilities of a tuple. .wildcards and .entities both directly return the `{wildcard}` string or list of values associated with the entity, but zip_lists still returns a dict of entity->values to be consistent with the `Expandable` protocol
- BidsPartialComponent - BidsComponentRow - Expandable
Allow the setting of uniqueness and the culling behaviour (removing some of the generated zip_list combinations) via strategy parameters Continue to Enforce dataset uniqueness in boolean filter tests Add detailed warning to the `test_when_all_custom_paths_no_layout_indexed` test, explaining why it might go beserk on failure because of the MockerFixture being used
Ensures 'datatype', 'suffix', and 'extension' are not used as the entity in `BidsComponentRow` so that paths can be safely derived
Add sphinx_design as docs dependency to allow the hiding of deprecated syntaxes Update docstrings
Updates all the filter tests to exclusively pass consumable iterators as arguments to filter methods
__spec is an optional, kw-only argument mutually exclusive with **filters that takes str or iterable of str to apply directly to the row's entity
Ensure only unique entries used in expand tests - Now that expand deduplicates paths, we need to test with deduplicated zip_lists
This will allow the addition of a second, optional position-only argument following it: __spec. It also frees the name paths for potential wilcard names, since paths is a valid wildcard name and right now there's a conflict
b019748
to
369c8e5
Compare
Resolves #243.
For a play-by-play of what I did, the commits are quite detailed and fairly well organized.
For a high level overview:
The new classes
BidsComponent
is conceived of as a multi-selectabledict
(sort of... actually right now only__getitem__
is implemented). If a tuple of entities is selected, you get back aBidsPartialComponent
which has aZipList
but nopath
orname
.BidsComponent
is actually just a subclass ofBidsPartialComponent
.If a single entity is selected from
BidsComponent
(orBidsPartialComponent
), you get aBidsComponentRow
. This represents a single entity and its values, and it's implemented as aImmutableList
(sort of aUserTuple
). It has thewildcards
andentities
properties, but instead of returning dicts, they directly return the{str}
or['list', 'of', 'values']
associated with the entity. This is to ensure symmetry between the following access modes:Note that the preferred style would still be
inputs['bold'].wildcards['subject']
, so this aspect of the new implementation is largely for consistency and to make everything more fail-proof.On the other hand,
BidsComponentRow.zip_lists
does still return a dict mapping the one entity to its ordered entity list. This break in symmetry is motivated by the newExpandable
protocol I established:Expandable
classes have anexpand
method, afilter
method, and azip_lists
property or attribute. The signatures of these items must be as found inBidsPartialComponent
. Thus,zip_lists
inBidsComponentRow
needs to return a dict in order to meet the protocol. In return, we're able to cleanly test all of three of the current classes using the exact same test code.Furthermore, because
BidsComponentRow
is already implemented as a list with immediate access to the values, any call from the user to a symmetrically definedzip_lists
would be completely redundant. It would give only a less powerful version of the list-like object the user already has.The documentation
I broke off a bit from our completely autogenerated documentation in the api section in order to prioritize the overview of
BidsComponent
.BidsPartialComponent
is really mostly a repeat ofBidsComponent
, so none of it's members are shown, just an extended docstring overview.BidsComponentRow
is rather different, so it's displayed in full.I also moved the
input_*
legacy properties into a dropdown box. I suppose we could technically deprecate them, but they don't really do any harm and dropping them would completely prevent older workflows from upgrading (unlikeBidsDataset.wildcards
etc, which probably never had much buy-in). This way we can document them and keep them, but out of the way.Deduplication
I decided that
zip_list
deduplication should not be performed immediately when getting subcomponents and rows. This is both for simplicity, and to ensure that indexing remains consistent and clear as capabilities become more complex. So the only deduplication to be performed will be done in theexpand
method (since it unambiguously doesn't make sense forexpand
to return multiple identical paths)Design Question
BidsComponentRow
as.entity
. The name is rather close to the.entities
property, which returns something completely different (the.entities
name doesn't make sense in isolation, but does if you consider the whole picture). So should we store.entity
as something else?TBD
zip_list
deduplication to theexpand
methods