return_scaled to return_in_uV

[h-mayorquin]

OK, so I open this PR for two reasons:

1. As you can see this will be a massive change and I think that someone (cc @samuelgarcia) really dislikes dealing with merge conflicts so maybe we could just change this in BaseRecording and co get_traces and deal with annoying deprecation messages for a while. That is, we fix the deprecations piecewise here and there.

2. The named proposed on the meeting, scale_to_uV, will clash with the preprocessing class of the same name. I have chosen return_in_UV as the interpolation of return_scaled and the discussed scale_to_uV but I am happy to change this. return_in_UV is regex-friendly so it should be easy to change if so we decide.

My own preference of course is to merge this as it is and get done with it.

[h-mayorquin]

We are going for the way it is now, return_in_uV and we are gonna merge this with all the changes in one go.

[yger]

Templates has also a field is_scaled. Should it be changed also ? If yes, sortingcomponents needs quite a lot of changes, because we are heavily using return_scaled and is_scaled

[zm711]

Templates has also a field is_scaled. Should it be changed also ? If yes, sortingcomponents needs quite a lot of changes, because we are heavily using return_scaled and is_scaled

I guess the better named attribute is is_in_uV. But is this suppose to be a private attribute or a public one (in the dev sense). We all know what is_scaled means so do you and Sam hope that some day people will use Template objects to make their own sorters? If so we should be consistent. If this is private and never should be used by others than it is less important to change.

[h-mayorquin]

I saw the template thing and I wanted to discussed on the previous maintenance meeting but I forgot. In any case, I think that changes should be its own PR.

[zm711]

Tests are passing and I know a lot of like to use keyword, but others on the team tend toward using positional arguments internally. So we risk:

check_recordings_equal(rec1, rec2, True, 'float32', True, False)

which would raise errors rather then putting the deprecation at the end which would allow things to work with positional as well and raise the error if using the wrong keyword. How are you thinking about this?

[zm711]

But my point is deprecating across multiple functions and I just took this one as an example.

[h-mayorquin]

We can move the old parameter to the end if you want.

[samuelgarcia]

Genial. Merci infiniment.
Lets merge this no ?

@yger Lets make another PR after the merge for Templates.is_scaled > Templates.is_in_uV