implement .b[] for boolean filtering and raise an error in arr[bool_key] when there is a bool axis

[gdementen]

As a follow-up to #735, we should actually decide what to do in that case. I am leaning towards this scheme:

if bool larray key:
    if self has a bool axis:
        has_common_axes = len(key.axes & array.axes) >= 1
        if has_common_axes:
            raise ValueError("boolean key is ambiguous because it can target either the array or the boolean axis")
        else:
            # target the bool axis
            <current non bool code>
    else:
        <current bool code>
else:
    <current non bool code>

[gdementen]

I have thought a lot more about this but I am really stuck.

Here is a summary of our options:

1. require groups with explicit axis when targeting a boolean axis. i.e. in array[bool_array], bool_array is always interpreted as a filter. This is what we have in larray 0.31. This is very annoying for LIAM2 in the short-to-medium term because boolean axes are very common there (because of a limitation of numexpr which cannot work with strings and larray not supporting categoricals). In the long term, there will probably be a better solution than those boolean axes but users already have them and I need a solution now.
2. (always) require an explicit method (for example .b[bool_array]) to filter. In that case array[whatever] always targets labels. This is by far the cleanest solution but I am unsure it is the best solution given that it is not backward compatible and may not be the most practical.
3. require an explicit method (for example .b[bool_array]) to filter only when there is a boolean axis. There are four sub-options:
   a. array[bool_array] would filter the array if there is no boolean axis, but would target the boolean axis if there is one.
   b. array[bool_array] would filter the array if there is no boolean axis, but would raise an "ambiguous" error if there is one (i.e. to target the boolean array you would need a group like in option 1.). At least this is explicit, but it does not solve my problem for LIAM2.
   c. array[bool_array] would filter the array if there is no boolean axis. If there is one and bool_array looks like a filter_key (has common axes with array), raise an "ambiguous" error, otherwise target the boolean axis. This is mostly what I described in the first comment of this issue and what I implemented in a branch (except .b[] is not implemented, hence when you have a boolean axis, you simply cannot filter an array that way anymore -- you would need to call array[bool_array.nonzero()] explicitly).
   d. (just for completeness), array[bool_array] would filter the array if there is no boolean axis or if there is one and bool_array looks like a filter_key (has common axes with array), otherwise it would target the boolean axis. This would probably be madness (too surprising).

Honestly I am kinda stuck. I am really not at ease with what I have implemented. It will come to bite us someday even though it works great in LIAM2 and it would not cause any problem with the current code of our current larray users (because current larray users simply do not use boolean axes).

Help!

[gdementen]

To paraphrase the options in my last message:

1. [] does both boolean filtering or targets axis labels with priority to boolean filtering in case of ambiguity (this is the current situation as of larray 0.31)
2. avoid ambiguity by moving boolean filtering to another method
3. a. [] does both boolean filtering or targets axis labels with priority to the axis labels in case of ambiguity (this is the exact opposite of option 1).
   b. [] does both boolean filtering or targets axis labels but raise an error in case of ambiguity.

[gdementen]

@alixdamman: Independently of the immediate problem in LIAM2 (which would require options 3.a or 3.c but which is better fixed in LIAM2 itself to avoid polluting larray with an unclean solution), I think the right thing to do would be to move to option 2 or 3b. Since option 2 is not backward compatible (and I think you are opposed to it anyway), are you okay with implementing option 3b in a future release (along with implementing a method to explicitly ask for boolean filtering such as .b)?

FWIW, 3b is theoretically not backward compatible but, in practice, it will most likely not cause any problem given that it is different only if there are boolean axes and such axes did not work for larray <= 0.30.

[gdementen]

moved to 0.33 as it is not urgent anymore

[alixdamman]

I'm OK with option 3.b.