The most obvious additional ability is that always

    >>> d[SOME_EXPRESSION]

is equivalent to

    >>> d[key]

for a suitable key.

This is a capability that we already have, which would sometimes be lost under the scheme you support.  Also lost would be the equivalence between

   >>> val = d[key]

   >>> getter = operator.itemgetter(key)

   >>> val = getter(d)

More exactly, sometimes it wouldn't be possible to find and use a key. Docs would have to be changed.

See: https://docs.python.org/3/library/operator.html#operator.itemgetter

As I understand it, xarray uses dimension names to slice data.  Here's an example from

    >>> da[dict(space=0, time=slice(None, 2))]

Presumably, this would be replaced by something like

    >>> da[space=0, time=:2]

Now, the commands

   >>> da[space=0, time=:2]

   >>>  da[space=0, time=:2] = True

   >>> del da[space=0, time=:2]

would at the begging of the call, presumably, do the same processing on the keyword arguments. (Let this stand for a wide range of examples.)

It is arguable that making it easier for the implementer of type(da) to do all that processing in the same place would be a REDUCTION of complexity.  Allowing the processing to produce an intermediate object, say

    >>> key = dict(space=0, time=slice(None, 2))

 would help here.

Real world examples are required, I think, to ground any discussions of complexity and simplicity. We want to optimise for what people do, for the problems they face. And this is a new feature.

The scheme you support does not distinguish

    >>> d[1, 2, x=3, y=4]

    >>> d[(1, 2), x=3, y=4]

I don't regard that as being perfectly good.

In addition, I would like

    >>> d = dict()

    >>> d[x=1, y=2] = 5

to work. It works out-of-the-box for my scheme. It can be made to work with a subclass of dict for the D'Aprano scheme.

I think that is enough for now.

I'd prefer to discuss this further by writing Python modules that contain code that can be tested. The testing should cover both the technical correctness and the user experience. To support this I intend not to focus on the next version of kwkey.

-- 

Jonathan