I may have allowed my frustration to run ahead of me, sorry.
There is a tonne of code that relies on subscripting positional
arguments to be bundled into a single parameter. Even if we agreed that
this was suboptimal, and I don't because I don't know the rationale for
doing it in the first place, I would be very surprised if the Steering
Council gave the go-ahead to a major disruption and complication to the
language just for the sake of making subscript dunders like other
functions.
Things would be different if, say, numpy or pandas or other heavy users
of subscripting said "we want the short term churn and pain for long
term benefit".
But unless that happens, I feel this is just a case of piggy-backing a
large, disruptive change of minimal benefit onto a a small, focused
change, which tends to ruin the chances of the small change. So please
excuse my frustration, I will try to be less grumpy about it.
I understand the grumpiness given your explanation. I'm really not wanting to derail that kwd args proposal-- I really like it,
whatever the semantics of it turn out to be.
I was actually trying to help the kwd arg case here.
As illustrated by the quote I included from Greg Ewing, there seems to be not even close to a consensus over what the semantic meaning of this should be:
m[1, 2, a=3, b=2]
Which could be made to mean one of the following things, or another thing I haven't considered:
1. m.__get__((1, 2), a=3, b=4) # handling of positional arguments unchanged from current behavior
2. m.__get__(1, 2, a=3, b=4) # change positional argument handling from current behavior
3. m.__get__((1, 2), {'a': 3, 'b': 4}) #
handling of positional arguments unchanged from current behavior
4. m.__get__(KeyObject(
(1, 2), {'a': 3, 'b': 4}
))
# change positional argument handling from current behavior only in the case that kwd args are provided
As Greg said:
These methods are already kind of screwy in that they don't
handle *positional* arguments in the usual way -- packing them
into a tuple instead of passing them as individual arguments.
I think this is messing up everyone's intuition on how indexing
should be extended to incorporate keyword args, or even whether
this should be done at all.
To illustrate the comments of "kind of screwy" and "the usual way", using semantic meaning # 1 above, then these are totally equivalent * :
m[1, 2, a=3, b=4]
m[(1, 2), a=3, b=4]
...even though these are totally different:
f(1, 2, a=3, b=4)
f((1, 2), a=3, b=4)
So my intention here isn't to derail, but to help the kwd argument proposal along by solving this screwiness problem.
It is to suggest that maybe a way forward-- to make the intuition of the semantics of kwd args to [ ] much more obvious-- would be to change the signature so that this incongruity between what happens with "normal" method calls and the "call" for item-get/set/del can be smoothed out.
If that incongruity were to be fixed, it seems to me it would become *obvious* that the semantic meaning of `
m[1, 2, a=3, b=2]` should definitely be:
m.__get__(1, 2, a=3, b=4)
But if all of this is not helping but hindering. I am happy to withdraw the idea.
* Citing my source: I borrowed these examples from Jonathan Fine's message in the other thread
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler