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
Oops. Should read Subject: Package kwkey to support Guido's favoured semantics
Please accept my apologies.