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
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/CN5F3ATZ6ICMBRQMZ623NLXVFTDTGCKK/
Code of Conduct: http://python.org/psf/codeofconduct/
