On Wed, 26 Aug 2020 at 17:50, David Mertz <mertz@gnosis.cx> wrote:
>
> In my mind, *anything* other than the straightforward and obvious signature `__getitem__(self, index, **kws)` is a pointless distraction.

It isn't.
and the reason why it isn't is that it makes it much harder for the
implementing code to decide how to proceed, for the following reasons:
1. you will have to check if the keywords you receive are actually in
the acceptable set
2. you will have to disambiguate an argument that is supposed to be
passed _either_ as position or with keyword. Always remember this use
case: a matrix of acquired data, where the row is the time and the
column is the detector.
I've seen countless times situations where people were creating the
matrix with the wrong orientation, putting the detector along the rows
and the time along the column. so you want this

acquired_data[time, detector]

to be allowed to be written as

acquired_data[time=time, detector=detector]

so that it's unambiguous and you can even mess up the order, but the
right thing will be done, without having to remember which one is
along the row and which one is along the column.

If you use the interface you propose, now the __getitem__ code has to
resolve the ambiguity of intermediate cases, and do the appropriate
mapping from keyword to positional. Which is annoying and you are
basically doing manually what you would get for free in any standard
function call.

Can you do it with that implementation you propose? sure, why not,
it's code after all. Is it easy and/or practical? not so sure. Is
there a better way? I don't know. That's what we are here for.

To me, most of the discussion is being derailed in deciding how this
should look like on the __getitem__ end and how to implement it, but
we haven't even decided what it should look like from the outside
(although it's probably in the massive number of emails I am trying to
aggregate in the new PEP).