[Python-ideas] Positional-only parameters
yselivanov.ml at gmail.com
Tue Feb 28 17:03:01 EST 2017
I'm +0.5 to add positional-only parameters.
* A lot of people don't know what '/' currently means in
functions signatures rendered by `help` and docs. Because
it's not a real syntax, it's really hard to find what it
* Some APIs do look better with positional-only parameters,
especially functions with one argument.
* We already have this feature half-implemented: some
builtin methods have positional-only arguments,
inspect.signature API supports it already.
* Function declarations will become a bit more complex,
making a bump in Python learning curve.
* Performance? I'm not sure if adding another set of checks
will make a huge impact, but we'll need to benchmark this.
On 2017-02-28 4:17 PM, Victor Stinner wrote:
> For technical reasons, many functions of the Python standard libraries
> implemented in C have positional-only parameters. Example:
> $ ./python
> Python 3.7.0a0 (default, Feb 25 2017, 04:30:32)
> replace(self, old, new, count=-1, /) # <== notice "/" at the end
>>>> "a".replace("x", "y") # ok
>>>> "a".replace(old="x", new="y") # ERR!
> TypeError: replace() takes at least 2 arguments (0 given)
> 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. `str.find('aaa')`
> 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
> Python 3.5 help (docstring) uses "S.replace(old, new[, count])".
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
More information about the Python-ideas