Hi Steven

You wrote:

why are we even considering a language change to force every single subscriptable object to accept arbitrary keyword-only arguments unless the maintainer changes their class to
explicitly reject them?

I think there might be a misunderstanding here. I'd like to see an example of where such a change would be required (see my conclusion below).

Recall that my proposal implies

>>> d = dict()

>>> d[a=1, b=2] = 42

>>> d[a=1, b=2]

Recall that your proposal implies

>>> d = dict()

>>> d[a=1, b=2] = 42

TypeError: wrapper __setitem__ doesn't take keyword arguments

Your statement above helps me understand the motivation for your proposal, for which I'm grateful. However, there might be a misunderstanding.

I'd like now to show you a consequence of my proposal. First consider

>>> lst = []

>>> lst['a']
TypeError: list indices must be integers or slices, not str

A dict will accept any hashable object as the key, but every list raises a type error if a string is passed as the index. No special action is required, for the list to reject a string as the index.

Let's see what happens when we pass a keyword key to a list.

>>> from kwkey import o
>>> lst = []
>>> lst[o(a=1)]
TypeError: list indices must be integers or slices, not K

My proposal implies that the following be equivalent

>>> anything[o(1, 2, a=3, b=4)]

>>> anything[1, 2, a=3, b=4]

for a suitable definition of 'o'. And kwkey I believe will provide such an 'o' (once the bugs have been removed - see below).

CONCLUSION

You wrote

why are we even considering a language change to force every single subscriptable object to accept arbitrary keyword-only arguments unless the maintainer changes their class to
explicitly reject them?

I don't see how this is a consequence of my proposal. To help me understand, please provide an example such as

>>> something[o(1, 2, a=3, b=4)] = 42

>>> something[o(1, 2, a=3, b=4)]

whose behaviour is unexpected or unwelcome. (You might want to wait until I've fixed the bug stated below.)

CONFESSION

There's a serious bug in kwkey. We don't have

>>> o(key) == key

True

but we should have that. Please accept my apologies.

I've reported the bug, and there'll be a new release next week.

https://github.com/jfine2358/python-kwkey/issues/2

Jonathan