Skip to content
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

[Feature]: Support len(processing_module) to get number of items #1993

Open
3 tasks done
rly opened this issue Nov 15, 2024 · 2 comments · May be fixed by #2020
Open
3 tasks done

[Feature]: Support len(processing_module) to get number of items #1993

rly opened this issue Nov 15, 2024 · 2 comments · May be fixed by #2020
Assignees
Labels
category: enhancement improvements of code or code behavior
Milestone

Comments

@rly
Copy link
Contributor

rly commented Nov 15, 2024

What would you like to see added to PyNWB?

A ProcessingModule is a special MultiContainerInterface that contains a labeled dictionary of NWBDataInterface objects called data_interfaces. It also has a description but nothing else. It's a bit unwieldy to call len(nwbfile.processing["behavior"].data_interfaces). It would be nicer to treat nwbfile.processing["behavior"] as a dictionary and be able to call len and other functions on it: len(nwbfile.processing["behavior"]).

For convenience, getitem works, e.g., nwbfile.processing["behavior"]["child1"], and I believe iterating works.

It might also be nice to move the other dictionary functions up to that level, e.g., keys, values, items.

Is your feature request related to a problem?

No response

What solution would you like?

See above.

Do you have any interest in helping implement the feature?

Yes.

Code of Conduct

@rly rly added the category: enhancement improvements of code or code behavior label Nov 15, 2024
@rly rly added this to the Future milestone Nov 15, 2024
@rly rly self-assigned this Nov 15, 2024
@h-mayorquin
Copy link
Contributor

I think this would make interacting with the API easier. +1 on moving all the dictionary machine directly to the object itself instead of within data_interfaces.

@bendichter
Copy link
Contributor

I like it.

The best counter-argument I can think of would be what if ProcessingModule gets extended is a way where these operations are ambiguous, e.g. if someone added some kind of list or dict like internal object where len would be a sensible operation. I don't think that's likely to happen, though. I don't think I have ever seen an extension of ProcessingModule, and if it were to happen I would guess it would be to add attributes-like metadata, not container-like data.

@bendichter bendichter linked a pull request Jan 27, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: enhancement improvements of code or code behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants