I am thinking at writing a PEP, yes. I need time to think about it, find all corner cases. Maybe also include something for "optional parameter without default value".
Don't expect it soon, I have some pending work to finish before :-)
Le 2 mars 2017 7:16 PM, "Brett Cannon" email@example.com a écrit :
It seems all the core devs who have commented on this are in the positive (Victor, Yury, Ethan, Yury, Guido, Terry, and Steven; MAL didn't explicitly vote). So to me that suggests there's enough support to warrant writing a PEP. Are you up for writing it, Victor, or is someone else going to write it?
On Tue, 28 Feb 2017 at 13:18 Victor Stinner firstname.lastname@example.org wrote:
For technical reasons, many functions of the Python standard libraries
$ ./python Python 3.7.0a0 (default, Feb 25 2017, 04:30:32)
help(str.replace) replace(self, old, new, count=-1, /) # <== notice "/" at the end ... "a".replace("x", "y") # ok 'a'
"a".replace(old="x", new="y") # ERR!
When converting the methods of the builtin str type to the internal "Argument Clinic" tool (tool to generate the function signature, function docstring and the code to parse arguments in C), I asked if we should add support for keyword arguments in str.replace(). The answer was quick: no! It's a deliberate design choice.
Quote of Yury Selivanov's message:
I think Guido explicitly stated that he doesn't like the idea to
always allow keyword arguments for all methods. I.e.
just reads better than
str.find(needle='aaa'). Essentially, the idea
is that for most of the builtins that accept one or two arguments,
positional-only parameters are better.
I just noticed a module on PyPI to implement this behaviour on Python functions:
My question is: would it make sense to implement this feature in Python directly? If yes, what should be the syntax? Use "/" marker? Use the @positional() decorator?
Do you see concrete cases where it's a deliberate choice to deny passing arguments as keywords?
Don't you like writing int(x="123") instead of int("123")? :-) (I know that Serhiy Storshake hates the name of the "x" parameter of the int constructor ;-))
By the way, I read that "/" marker is unknown by almost all Python developers, and [...] syntax should be preferred, but inspect.signature() doesn't support this syntax. Maybe we should fix signature() and use [...] format instead?
Replace "replace(self, old, new, count=-1, /)" with "replace(self, old, new[, count=-1])" (or maybe even not document the default value?).
Python 3.5 help (docstring) uses "S.replace(old, new[, count])".
Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/