On Sat, 6 Feb 2021 at 08:56, Batuhan Taskaya firstname.lastname@example.org wrote:
Lurking around the discussions I started to wonder whether this syntax actually worths the burden it introduces.
It has been discussed for weeks on py-ideas.
As you have commented out earlier, there are no use cases in the built-in types, perhaps a research would be great regarding possible use cases of keyword arguments in and out of the stdlib.
Nor there is for the @ operator, but it is still relevant for external libraries.
Now looking at PEP 637, even with the theoretical examples given, it seems like we are introducing a redundant syntax that has no other value than just complicating the already complex subscript notation and becoming a bad alternative to function call syntax.
you can't do:
f(x, y=3) = 5
but you can do
a[x, y=3] = 5
pandas has relied on workarounds like iloc() to work around the lack of an indexing operator with keyword arguments, and we need them anyway for specifying types, now that the indexing operator is "abused of notation" all the time for typing.
Of course the meaning of a[x, y=3] = 5 is up to the implementation of a. We don't prescribe anything on that.
On Tue, Feb 2, 2021 at 2:40 PM Stefano Borini email@example.com wrote:
I would like to request feedback by python-dev on the current implementation of PEP 637 - Support for indexing with keyword arguments.
The PEP is ready for SC submission and it has a prototype implementation ready, available here (note, not reviewed, but apparently fully functional)
(note: not sure if there's a preference for the link to be to the diff or to the branch, let me know if you prefer I change the PEP link)
Thank you for your help.
-- Kind regards,
Stefano Borini _______________________________________________ Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/E3AMOIB3... Code of Conduct: http://python.org/psf/codeofconduct/