On Fri, Jul 10, 2020 at 2:33 PM Steven D'Aprano <[email protected]> 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.
_______________________________________________
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/EMJSDLKJ3FPXZNBMZJFZ4I5L34DKAVG3/
Code of Conduct: http://python.org/psf/codeofconduct/
