On Fri, Jul 10, 2020 at 2:33 PM Steven D'Aprano <steve@pearwood.info> wrote:

On Fri, Jul 10, 2020 at 11:52:19AM +0100, Jonathan Fine wrote:

> FUTURE
> Let's proceed. We continue to use d = Dummy(). Given that
> >>> key = d[1, 2, 3, a=4, b=5]
> is allowed, what should we be able to say about the key. Clearly it should
> be an instance of a class

That's not clear at all.

Subscripting is just syntactic sugar for a method call, `__getitem__`,
and we already know how to associate positional and keyword arguments to
method calls. No special magic class is needed.
...
There would be difficulty with positional arguments, since they are
already parsed as a tuple:

py> {(1,2): 999}[1,2]
999

so this may rule out adding multiple positional arguments to
subscripting syntax. But I don't think there is any backwards
compatibility issue with adding keyword arguments.

Jonathan already pointed out that positional arguments are passed as a tuple:

Here goes:

>>> d = Dummy()
>>> d[1]
((1,), {})
>>> d[1, 2]
(((1, 2),), {})
>>> d[:]
((slice(None, None, None),), {})
>>> d['a':'b']
((slice('a', 'b', None),), {})
We see that the interpreter passes to __getitem__ a single positional argument (which is usually called the key). This is another difference between d[something] and f(something).

I believe he was saying it would be weird if `d[1, 2]` called `d.__getitem__((1, 2))` but `d[1, 2, x=3]` called `d.__getitem__(1, 2, x=3)`. More generally, if `__getitem__` always receives a single positional argument now, it should probably stay that way for consistency.