The only thing I was thinking about was if the plan is to release the SortingAnalyzer before the conference it might make sense to try to do these before the release, no? That way we get a bunch of "breaking" api changes all at once again. Or would we prefer to do the deprecation style of so that we don't really break the api?

if old_arg is not None:
    warn(xxx)
    new_arg = old_arg

Thanks @alejoe91! Looks great, one additional aim I might add would be to identify parts of the API that developers are not happy with / think could be improved in future. Then if there is consensus these could all be changed at the same time. This would help limit the number of tweaks needed in future.

As a user, I noticed that the input arguments of run_sorter and run_sorter_by_property could be standardized

My colleagues and I have noticed API inconsistencies and think this proposal is a splendid idea. I would like to contribute to this project in Edinburgh.

-Nikhil Chandra

Adding some data point, the functions for settings the probe, we have set_probe, set_probes and set_probe_group. The first and the third use the second, mabye that one should be private?

Related:
SpikeInterface/spikeinterface#1989

We have get_channel_property which duplicates get_property and there is no get_unit_property. I think it should be one way or the other.

Potentially interested in contributing during the hackathon 🙂

That's awesome @jakeswann1. Welcome aboard!

• Visualize/Vizualise: IMO we should stick to american english!

Great point. I'll watch out for it!

has_scaled vs has_scaled_traces

copy instead of the current clone for both recording and sorting objects:

https://github.com/SpikeInterface/spikeinterface/blob/70ebe171ba311ddb2c34cd2992c9a65875eedf1a/src/spikeinterface/core/base.py#L526-L534

Maybe between calculate and compute from compute_quality_metrics and calculate_pc_metrics