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)) >> >> 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/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/NKBXBORVUA6TF5FZ3P72DPSAPPAJLMAE/ Code of Conduct: http://python.org/psf/codeofconduct/
