Corr.__getitem__ unexpected behaviour about pyerrors HOT 4 OPEN

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.

from pyerrors.

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?

from pyerrors.

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.

from pyerrors.

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?

from pyerrors.