-
Notifications
You must be signed in to change notification settings - Fork 215
Standardising parts of the API. #2303
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
Comments
Thanks for this write up, @JoeZiminski (and @zm711 ). I agree that we should unify the API wherever we can. For |
|
So what should be for preprocessing? |
Most function/classes in the spikeinterface have a positional argument labeled as recording (so I switched the docs to use keyword to encourage people to use the keyword instead), so the path of least resistance (and most consistent for people) would be to use |
I actually do find some value on the fact that I would rather use |
I would be fine if every preprocessor took in |
I agree |
|
Hey @alejoe91 @zm711 @h-mayorquin I thought I'd resurrect this thread considering (as I understand it) the current work on #2282 is being wrapped up and docs being written. I wonder if it is even worth spending an afternoon (or possible hackathon for the meet-up) going through the entire API and categorising function names / arguments into:
However this is a lot of work so appreciate it might not be a priority at the moment or might be better later as a standalone endeavour-if |
I like that @JoeZiminski ! I can think a little API polish might be nice :) |
Hackathon project? |
Following a conversion in #2299, a number of instances where the API is inconsistent were highlighted. This issue is opened as a place to discuss and begin fixing these:
ZeroChannelPaddedRecording
saves it's parent recording to aparent_recording
kwarg not arecording
kwarg that seems to be used elsewhere.ZeroSilencePeriods
stores the parent recording as a dict not a recording.CurationSorting
uses aparent_sorting
rather thansorting
folder
vs.output_folder
argument.More genreally, I think SI is becomming a very mature and widely used package and freezing the API / defaults as much as possible between versions would really enhance user experience / avoid bugs. I wonder if at some stage a full review of the API could be performed (this would entail multiple people going through every SI function / class and making notes on function names and default arguments inconsistencies or room for improvement). Then these could be discussed, frozen, and only changed in future with a very good reason. I wonder what people think about this.
The text was updated successfully, but these errors were encountered: