search

lina-usc / pylossless

🧠 EEG Processing pipeline that annotates continuous data
https://pylossless.readthedocs.io/en/latest/
MIT License
15 stars 8 forks source link

Decide on API #122

Closed scott-huberty closed 8 months ago

scott-huberty commented 1 year ago

While API is on my mind - We should make a decision on what we want our public API to be and make everything else private.

This will help organize the package and will make it clear to us which functions/methods are public and thus should be stable. It also relieves us of documenting/maintaining functions that are only used internally.

CC @Andesha

EDIT: FYI, during development almost nothing was made private... This is why I'm bringing it up now.

christian-oreilly commented 1 year ago

It is unlikely that we will change a function from private to public. Maybe just listing the public functions that you think should be made private and we can discuss these, specifically? I am not a big fan of trying to put everything private (not saying that it is what you aim to do)... I'd avoid putting private anything that might have an external use (even though we may not have coded it with this in mind) and putting private only what is very specific to the internals and unlikely to ever be useful for re-use... I am not rigid on that position, but that is how I see it at this point. This is a research tool, aim at researchers who are expected (and should feel welcome) to play with the code beyond the narrowly drawn borders of the use case we may have thought about...

scott-huberty commented 1 year ago

Sure, I can propose a list of functions that should not be part of the API.

I agree with you that there are some utilities outside the main pipeline methods that can be useful and be a part of the API.