On Sat, Jul 18, 2020 at 9:11 PM Christopher Barker <pythonchb@gmail.com> wrote:
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))
Not to this... 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)
But to this.
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.
These two paragraphs make it clear what Steven was proposing. I am supporting him in this.
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>