On Sat, Jul 18, 2020 at 9:11 PM Christopher Barker <python...@gmail.com> wrote:
> > > On Sat, Jul 18, 2020 at 1:43 PM Guido van Rossum <gu...@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 <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)) >>> >> 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/>
_______________________________________________ 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/Q3THDB35R4AQIK4JSNYBM5XFSOPQQZ66/ Code of Conduct: http://python.org/psf/codeofconduct/
