Add Template class

[h-mayorquin]

First draft. I am putting this out early to get feedback.

Right now the class implements two functionalities.

1. Looking around in the repo, it seems that all the uses of templates assume that the object is a numpy array. The new class has functionality so this assumption is stil valid. That is, the new template class behaves like a numpy array: it can be sliced like a numpy array, and you can use any ufunct (.e.g. np.mean). For this see the test.
2. Serialization: both json and pickle are implemented and tested.

[h-mayorquin]

@alejoe91 @samuelgarcia
This is ready for another round of review. Let me know if this is lacking any properties that you think should go here.

The only thorny issue for me is mismatch between passing a templates_array that is dense but a sparsity mask. We have some options:

• Either throw an error.
• Sparsify in the post-init if not sparse.
• Let ir run and handle problems downstream.

I prefer the first but knowing that you like permisive methods and flexibility we have 3.

[alejoe91]

@alejoe91 @samuelgarcia This is ready for another round of review. Let me know if this is lacking any properties that you think should go here.

The only thorny issue for me is mismatch between passing a templates_array that is dense but a sparsity mask. We have some options:

• Either throw an error.
• Sparsify in the post-init if not sparse.
• Let ir run and handle problems downstream.

I prefer the first but knowing that you like permisive methods and flexibility we have 3.

@h-mayorquin I agree that in that case we should throw an error in the post_init

[alejoe91]

@h-mayorquin we reached the deprecation deadline!!

https://github.com/SpikeInterface/spikeinterface/blob/main/src/spikeinterface/extractors/cellexplorersortingextractor.py#L56-L59

Fixed here: #2048

[zm711]

One question for the docstring. Is there a design reason why you wouldn't want nbefore and nafter next to each other in the docstring? I'm not super used to data classes in general so maybe the docstring is enforced in this way, but at least from an ease of reading for me it would make sense to have the related concepts together.

[zm711]

One other comment based on my googling kw_only is a 3.10+ ( I think 3.8 and 3.9 are suppose to be supported).
https://docs.python.org/3/library/dataclasses.html

[alejoe91]

@h-mayorquin can you remove it then?

[h-mayorquin]

Yes.
This is another shortcoming of only having tests for python 3.10 only.

[alejoe91]

Very minor docstring changes, then it's good to go for me! Thanks @h-mayorquin

[samuelgarcia]

Not sure to be happy with this.
This is computationaly costy. For me the shape is enough.

[alejoe91]

ok for now. If this becomes problematic later we'll fix it.

NOTE: this assumes that the extra channels are zero-padded!

[h-mayorquin]

Added a boolean to deactivate this.

[h-mayorquin]

Thanks for the comments about the docstrings @zm711 . I drop this for a bit but I am back to it and will change them.

[h-mayorquin]

@zm711
Docstring related.
I don't have a good solution for this. n_before is required for the instantiation of the class but n_after is not. I separated parameters from the construction from the attributes in the latest docstring. If you have any suggestion or alternative models for how to do docstirng of dataclassess I am all ears.

[zm711]

I think dividing the parameters like you have looks nice and clears up the confusion of having related parameters so spread about (for me at least). Thanks @h-mayorquin

[h-mayorquin]

This is should be ready btw @alejoe91 @samuelgarcia