On Sat, 8 Aug 2020 at 02:34, Stephan Hoyer <shoyer@gmail.com> 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.