Repository navigation
make arr['key1;key2'] work #904
Description
Activity
- added a commit that references this issue
on Oct 11, 2021 Moving this issue and the corresponding PR to milestone 0.35 because it makes ';' ambiguous in the context of group aggregates. For example:
arr.sum('a2;b1..b3')
currently means two groups on the same axis. We have two options here:
- either use another separator between groups on the same axis. This would be cleanest but would break backward compatibility. For example, in the following there would be a b1,b2,b3,b5 group and another b7,b8,b9 group:
arr.sum('a1,a3;b1..b3,b5/b7:b9')
- somehow (unsure it is possible to implement this easily/without introducing some ambiguous cases) allow several groups from the same axis and groups from different axes using the same separator. For example, make this work:
arr.sum('a1,a3;b1..b3,b5;b7:b9')
In that case, we could require the groups to be enclosed by
[ ]or( )and separate groups on the same axis by,(but that would be backward incompatible)arr.sum('a1,a3;[b1..b3],[b5:b7]')
Either way, this needs more thoughts.
@alixdamman : if you have any idea on how to solve this, please speak 😉
In that case, we could require the groups to be enclosed by
[ ]or( )and separate groups on the same axis by,(but that would be backward incompatible)arr.sum('a1,a3;[b1..b3],[b5:b7]')
Using
[and]seems like a bad idea to me now because we cannot reproduce this outside the string syntax and it makes the[kinda ambiguous.Using
(and)around the different groups on the same axis would make more sense I think (this would match pretty closely with what we need to do with the non-string syntax):# match two groups -> group aggregate arr.sum('a1,a3;(b1..b3,b5;b7:b9)') # a single group -> axis disappears arr.sum('a1,a3;b1..b3,b5,b7:b9')
In any cases (parentheses or not), we will need to decide if we want to support this:
# match two groups on b -> group aggregate arr.sum('a1,a3;b1..b3,b5;b7:b9')
Currently one has to write:
even though key1 and key2 can be "string keys". So I don't see any reason to disallow going one step further.
See also #151
For example: