<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 1, 2017 at 11:25 AM, Serhiy Storchaka <span dir="ltr"><<a href="mailto:storchaka@gmail.com" target="_blank">storchaka@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 28.02.17 23:17, Victor Stinner wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My question is: would it make sense to implement this feature in<br>
Python directly? If yes, what should be the syntax? Use "/" marker?<br>
Use the @positional() decorator?<br>
</blockquote>
<br></span>
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.<br></blockquote><div><br></div><div>Agreed.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<span class="gmail-"><br></span></blockquote><div><br></div><div>It's in a sense a pun -- * and / are "opposites" in mathematics, and so are the usages here.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Do you see concrete cases where it's a deliberate choice to deny<br>
passing arguments as keywords?<br>
</blockquote>
<br></span>
dict.__init__(), dict.update(), partial.__new__() and partial.__call__() are obvious examples. There are others.<br>
<br>
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.<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Don't you like writing int(x="123") instead of int("123")? :-) (I know<br>
that Serhiy Storshake hates the name of the "x" parameter of the int<br>
constructor ;-))<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<span class="gmail-"><br></span></blockquote><div><br>+1<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
By the way, I read that "/" marker is unknown by almost all Python<br>
developers, and [...] syntax should be preferred, but<br>
inspect.signature() doesn't support this syntax. Maybe we should fix<br>
signature() and use [...] format instead?<br>
</blockquote>
<br></span>
[...] 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.</blockquote></div><br></div><div class="gmail_extra">FWIW in typeshed we've started using double leading underscore as a convention for positional-only parameters, e.g. here:<br><br><a href="https://github.com/python/typeshed/blob/master/stdlib/3/builtins.pyi#L936">https://github.com/python/typeshed/blob/master/stdlib/3/builtins.pyi#L936</a><br><br></div><div class="gmail_extra">FWIW I think 'self' should also be special-cased as positional-only. Nobody wants to write 'C.foo(self=C())'. :-)<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/%7Eguido" target="_blank">python.org/~guido</a>)</div>
</div></div>