Do you have an example from boost-histogram..
One of the dev's here, and actually, I think "Hist" would use it, rather than boost-histogram directly. In boost-histogram, axis are only represented by numbers, so `h[{0:slice(2,5)}]` probably could not be written `h[0=2:5]` even after this PEP; but we could have ax0, etc, for example. See the SciPy 2020 or PyHEP 2020 talks for more examples. Hist extends boost-histogram and adds named axes, where this would be _very_ useful. Now you could make a histogram: ```pyhton h = Hist(axis.Regular(10,-1,1, name="x"), axis.Boolean(name="signal")) h_signal= h[x=2:8, signal=True] ``` (of course, you could actually have a lot of axes, and you don't need to slice all of them every time) I realize now on further reading the PEP does discuss the idea, though I only agree with one of the arguments; the slow part might be solvable, the complexity issue is reversed (adding a new one-off rule ontop of the _already_ one-off rule for tuplizing arguments is more complex, IMO, than reusing function syntax), the transition/mix could be done, the one where "*args" would be needed to represent a tuple of arguments makes no sense to me (of course that's how you should write a Python signature for a variable number of args, that's not a downside). It would be reasonably easy to write a conversion to/from `__getitem_func__`, and the end result would be a cleaner, nicer language (in 10ish years?). There have been similar transitions in the past. Furthermore, you currently can't tell the difference between `x[(a, b)]` and `x[a, b]`; with the new function, libraries could differentiate, and maybe eventually make them behave reasonably (you can always use x[*c] if you already have a tuple, just like for a function, and it's one of the rare / only places where list vs. tuple matters in Python). Just some thoughts, still excited to see this become available in some form. :)