[Python-ideas] Positional-only parameters

[Guido van Rossum]

On Wed, Mar 1, 2017 at 11:25 AM, Serhiy Storchaka <storchaka at gmail.com>
wrote:

> On 28.02.17 23:17, Victor Stinner wrote:
>
>> 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?
>>
>
> I'm strongly +1 for supporting positional-only parameters. The main
> benefit to me is that this allows to declare functions that takes arbitrary
> keyword arguments like Formatter.format() or MutableMapping.update(). Now
> we can't use even the "self" parameter and need to use a trick with parsing
> *args manually. This harms clearness and performance.
>

Agreed.


> The problem with the "/" marker is that it looks ugly. There was an excuse
> for the "*" marker -- it came from omitting the name in "*args". The "*"
> prefix itself means an iterable unpacking, but "/" is not used neither as
> prefix nor suffix.
>

It's in a sense a pun -- * and / are "opposites" in mathematics, and so are
the usages here.


> Do you see concrete cases where it's a deliberate choice to deny
>> passing arguments as keywords?
>>
>
> dict.__init__(), dict.update(), partial.__new__() and partial.__call__()
> are obvious examples. There are others.
>
> And there was performance reason. Just making the function supporting
> keyword arguments added an overhead even to calls with only positional
> arguments. This was changed recently, but I didn't checked whether some
> overhead is left.
>
> 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 ;-))
>>
>
> I believe weird names like "x" was added when the support of "base"
> keyword was added due to the limitation of PyArg_ParseTupleAndKeywords().
> All or nothing, either builtin function didn't support keyword arguments,
> or it supported passing by keyword for all arguments.
>
> But now it is possible to support passing by keyword only the part of
> parameters. I want to propose to deprecate badly designed keyword names of
> builtins.
>

+1


> 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?
>>
>
> [...] is not Python syntax too. And it is orthogonal to positional-only
> parameters. [...] doesn't mean that parameters are positional-only. They
> can be passed by keyword, but just don't have default value. On other side,
> mandatory parameters can be positional-only.


FWIW in typeshed we've started using double leading underscore as a
convention for positional-only parameters, e.g. here:

https://github.com/python/typeshed/blob/master/stdlib/3/builtins.pyi#L936

FWIW I think 'self' should also be special-cased as positional-only. Nobody
wants to write 'C.foo(self=C())'. :-)

-- 
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170301/5017a03e/attachment.html>