Corr.__getitem__ unexpected behaviour

[jkuhl-uni]

Hi,
so, I was using the Corr class the other day and I found that there is a small issue, when picking ranges of timeslices from a correlator using slicing.
When using one item from a correlator, such as pe.Corr[10] on a correlator that has a single value per timeslice (i.e. is no matrix valued Correlator),
I receive a pe.Obs back, as expected.
However, if I use pe.Corr[10:12] in the same correlator, I receive an object of the form list[np.ndarray(pe.Obs), np.ndarray(pe.Obs)], where the inner arrays hold one pe.Obs item.
This should come from pe.Corr line 126, which evaluates to 2 == 1 -> False in the second case, as the slicing is handed over in a weird way.
This is not a pyerrors specific problem, but maybe we should circumvent this somehow?
Cheers
Justus

[s-kuberski]

Hi,
I had looked at this in the past. Basically, in my opinion, it is a bug in the way the slicing is defined for the correlator and it could be corrected such that you would really get a list of observables instead of these weird arrays. Actually, it would make ones life a lot easier in some cases. However, I was hesitant to propose to change this because it could be a breaking change for analyses if someone was using [o[0] for o in corr[10:30]] to circumvent the current issue. The workaround that would not be affected is [o for o in corr][10:30]. Both are a bit ugly compared to the simple corr[10:30] that one would like to work.

I don't know what you opinion on this would be.

[fjosw]

I also remember discussing this with @s-kuberski some time ago. So far we have been very strict about not introducing breaking changes in minor releases. Should we consider making an exception here or, do we want to stick to our policy?

[s-kuberski]

I am not sure. It is the question if you consider this fixing a bug or introducing a breaking change, but I think the semantic versioning would tell you not to break the behavior anyways, right? I am fine with not fixing this for now, although any workaround that would break when this is fixed might be introduced in more and more workflows the longer we keep it in here. I personally would also be able to adapt my codes to work with the new behavior.

[jkuhl-uni]

Hi,
sorry to come back to you just now, I had some trouble with my github :)
Personally, I would also be able to adapt my analyses to this change, however, I understand that this would break other analyses. I think we could wait for a potential new mayor release to fix this, where we could also fix other breaking stuff, if we find more. Could that be a solution?