On Tue, Aug 25, 2020 at 4:41 PM Stefano Borini
On Sat, 8 Aug 2020 at 02:34, Stephan Hoyer
wrote: I'm sorry, I did a poor job of editing this.
To fill in my missing word: From my perspective, the *only* reasonable way to add keyword arguments to indexing would be in a completely backwards compatible way with **kwargs.
Let me clarify that I don't like the kwargs solution to the current getitem, and the reason is simple.
The original motivation for PEP-472 was to do axis naming, that is, to be sure you would be able to clearly indicate (if you so wished) data[23, 2] explicitly as e.g. data[day=23, detector=2] or data[detector=2, day=23]
But that assumes that all keyword axes can be mapped to positional axes. This is not the case in xarray, there are axes that are keyword-only. And it precludes other uses-cases that have been mentioned, such as parameters for indexing. So I understand that this was the original motivation, I don't think it is good to restrict to it only this use-case when there are other valid use-cases.
If you have **kwargs, now the first case would send the two values to the nameless index, the second case to the kwargs, and inside the getitem you would have to reconcile the two, especially if someone then writes data[24, 5, day=23, detector=2] typing of course has the same issue. What this extended syntax is supposed to be used for is to define specialisation of generics. but it's difficult to now handle the cases List[Int] vs List[T=Int] vs List[Int, T=int], which are really telling the same thing the first two, and something wrong (TypeError multiple arguments) the second.
That is a problem that anyone using **kwargs in functions has to deal with. It is neither a new problem nor a unique one, and there are plenty of ways to deal with it.