The next release of kwkey will provide a class A with the following property.

It is that
    >>> A(1, 2, a=3, b=4)[d] = 'val'
will result in
    >>> d.__setitem__((1, 2), 'val', a=3, b=4)

This is precisely the same call that would result from
    >>> d[1, 2, a=3, b=4] = 'val'
using the semantics that Guido currently favours.

Further, to better support exploration, the call instead will be
   >>> d._A_setitem__((1, 2), 'val', a=3, b=4)
when d._A_setitem__ exists. (And of course similar behaviour for getitem and delitem.)

This will allow experiments via subclassing an existing class, for example from xarray. Using _A_setitem__ etc means that the new
    >>> A(1, 2, a=3, b=4)[d] = 'val'
semantics can be implemented via the already existing
   >>> d[SOMETHING] = 'val'
implementation.

Both the commands
    >>> d[SOMETHING] = 'val'
    >>> A(1, 2, a=3, b=4)[d] = 'val'
can thus work on the same mapping / sequence instance d. The two implementations can peacefully co-exist.

For clarity, when available
    >>> d[1, 2, a=3, b=4] = 'val'
is most likely to be better than
    >>> A(1, 2, a=3, b=4)[d] = 'val'
and I introduce the A second form as a useful stopgap, until the first form is available.

A reminder. The purpose of kwkey is to provide a convenient way for people to experiment with different approaches to implementing the semantics of
    >>> d[1, 2, a=3, b=4] = 'val'
and, perhaps, to provide a compatible implementation in present day Python. For fairness, I hope also to provide a class B that supports the __keyfn__ semantics.

I hope to make this release next week. Comments are welcome.

https://pypi.org/project/kwkey/
https://github.com/jfine2358/python-kwkey/issues/3

-- 
Jonathan