On Sat, Aug 29, 2020 at 7:30 PM Steven D'Aprano <steve@pearwood.info> wrote:
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.

 That's a fair ruling. In general, when keywords are present, the rule that you can always omit an outermost pair of parentheses is no longer true. That is, d[(...)] and d[...] are always equivalent regardless what "..." stands for, as long as (...) is a valid expression (which it isn't if there are slices involved). Example:
```
d[1]  ~~~  d[(1)]
d[1,]  ~~~  d[(1,)]
d[1, 2]  ~~~  d[(1, 2)]
```
But there is absolutely no such rule if keywords are present.

FYI, Jonathan's post (once I "got" it) led me to a new way of reasoning about the various proposals (__keyfn__, __subscript__ and what I will keep calling "Steven's proposal") based on what the compiler and interpreter need to do to support this corner case. My tentative conclusion is that Steven's proposal is superior. But I have been reviewing my reasoning and pseudo-code a few times and I'm still not happy with it, so posting it will have to wait.

--
--Guido van Rossum (python.org/~guido)