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/