On Wed, Mar 1, 2017 at 11:25 AM, Serhiy Storchaka <storch...@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>)
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
