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] 42 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