On Sat, Jul 18, 2020 at 1:43 PM Guido van Rossum <guido@python.org> wrote:

Yes please.

Yes to what, exactly?

-CHB

FWIW, IIRC the “bundle values in a single parameter” predates the demise of __getslice__. It probably was meant for dict keys primarily (no surprise there). The bundling would have been easier for the C API — __getitem__ is as old as Python there.

On Sat, Jul 18, 2020 at 10:49 Steven D'Aprano <steve@pearwood.info> wrote:

On Sat, Jul 18, 2020 at 05:30:40PM +0100, MRAB wrote:

> I haven't followed this thread for a while, but, to me, it seems that
> the simplest option would be to pass the keyword arguments as a dict:

What are you going to do with that keyword argument dict?

Most use-cases I can think of will have to unpack the dict into named
parameters. (Just as the interpreter does for us, in function calls.)

When I'm writing functions, for every one use of `**kwargs`, I have
about a hundred uses of named parameters. I'm pretty sure most people
are similar. I don't think that keyword args in subscripts will be
different. I'm pretty sure that nearly everyone will want to unpack the
`**kwargs` into named parameters nearly all of the time.

So why force them to do the unpacking themselves when the interpreter
already has all the machinery to do it?

If you want kwargs to collect arbitrary keyword arguments, you can just
declare your getitem method (and setitem and delitem if needed) to take
`**kwargs`, and the interpreter will oblige.

If you want no keyword arguments at all, you don't have to change a
thing. Your getitem (etc) methods have no keyword parameters, so using
keywords in the subscript will fail with TypeError.


>     obj[a, b:c, x=1] does obj.__getitem__((a, slice(b, c)), dict(x=1))

I don't think that is either simpler or more useful than a straight-
forward binding of arguments to parameters, just as function calls
already do:

    obj[a, b:c, x=1] ==> obj.__getitem__((a, slice(b, c)), x=1)

It's unfortunate that positional subscripts are bundled together into a
tuple. I have resisted calling that design a "mistake" because I don't
know the reason for the design. There was probably a good reason for it,
back in the ancient history of Python when getslice and getitem were
unified. But I am sure that it will be a horrible mistake to emulate
that decision for keyword arguments.

If anyone wants or needs their keyword arguments to be bundled into a
single kwargs parameter, you can have it. All you need do is declare
your method with a `**kwargs` parameter, and the interpreter will do the
rest.