Yes please. 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 <st...@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. > > > > -- > Steven > _______________________________________________ > 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/5MAWLGDJCVM62N7CKKY3C5DBYKVTWZHC/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile)
_______________________________________________ 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/NAWEMP4FPLZPP7X4A4IND7IQEMB62CFL/ Code of Conduct: http://python.org/psf/codeofconduct/
