[Python-ideas] Positional-only parameters

Matthias Bussonnier bussonniermatthias at gmail.com
Tue Feb 28 17:08:53 EST 2017


I think that was started as pep 457:

https://www.python.org/dev/peps/pep-0457/ (Syntax For Positional-Only
Parameters)
Still informal.


+1, it's likely possible to backport it to previous version using a
decorator and faking __signature__.

-- 
M


On Tue, Feb 28, 2017 at 2:03 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> I'm +0.5 to add positional-only parameters.
>
> Pros:
>
> * 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
> means.
>
> * 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.
>
> Cons:
>
> * 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.
>
> Yury
>
>
>
> On 2017-02-28 4:17 PM, Victor Stinner wrote:
>>
>> Hi,
>>
>> 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)
>>>>>
>>>>> 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!
>>
>> 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.
>> """
>> http://bugs.python.org/issue29286#msg285578
>>
>> I just noticed a module on PyPI to implement this behaviour on Python
>> functions:
>>
>>     https://pypi.python.org/pypi/positional
>>
>> 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])".
>>
>> Victor
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/


More information about the Python-ideas mailing list