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