On Sat, Aug 29, 2020 at 04:31:53PM -0700, Guido van Rossum wrote:
> On Sat, Aug 29, 2020 at 4:08 PM Guido van Rossum <gu...@python.org> wrote:
>
> > [...]
> > Finally, I am unsure how you would deal with the difference between d[1]
> > and d[1,], which must be preserved (for `__keyfn__ = True` or absent, for
> > backwards compatibility). The bytecode compiler cannot assume to know the
> > value of `__keyfn__` (because d could be defined in another module or could
> > be an instance of one of several classes defined in the current module). (I
> > think this problem is also present in the `__subscript__` version.)
> >
>
> This problem is actually also present in Steven's version (which just
> passes keyword args as **kwargs to `__getitem__` and `__setitem__`). We
> could treat d[1, a=3] either as d[1,] + kwargs or as d[1] + kwargs. Have
> people debated this yet?
Good catch!
I don't think that anyone wants adding a keyword to a single-valued
subscript to change it to a tuple. At least, I really hope that nobody
wants this!
So given the current behaviour:
obj[1] # calls __getitem__(1)
obj[1,] # calls __getitem__((1,))
I expect that the first will be the most common. If we add a keyword to
the subscript:
obj[1, a=3]
I would expect that the it turns into `__getitem__(1, a=3)` which is
almost surely what the reader and coder expects. It would be quite weird
for the subscript 1 to turn into a tuple just because I add a keyword.
That does leave the second case a little trickier to add a keyword to,
it would require a pair of parens to disambiguate it from above:
obj[(1,), a=3]
but I think that's likely to be obvious to the developer who is adding
in the keyword where previously no keyword existed.
--
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/IPJKP4ZM4CYNB7NKML6LDG7WZBKMNFWQ/
Code of Conduct: http://python.org/psf/codeofconduct/
