[Python-Dev] PEP 457: Syntax For Positional-Only Parameters

Nick Coghlan ncoghlan at gmail.com
Thu Oct 10 00:57:44 CEST 2013


On 10 Oct 2013 00:17, "Larry Hastings" <larry at hastings.org> wrote:
>
>
> On 10/09/2013 11:46 AM, Nick Coghlan wrote:
>>
>> Generally, it needs to be a bit clearer that the intent of the PEP isn't
to say "let's do this", it's to be explicit that acceptance of the Argument
Clinic PEP severely constrains the design space for possible solutions if
we ever *did* implement Python level support for positional only arguments.
>
>
> Can you suggest an edit that would make you happy?

PEP title: Representation of positional-only parameters

(Removes the loaded word "Syntax for")

The abstract would then draw from your reply to Benjamin: adding
introspection support for builtins and extension modules means we need a
way to represent positional-only parameters that can't be expressed using
the normal function definition syntax.

>> - parameters in optional groups should just have an implied "=None" that
can be overriden if desired.
>
>
> No no no!  You can't have a default value, and you definitely couldn't
use None.
>
> range() decides what its arguments mean based on how many arguments it
receives.  If I understand your proposal correctly, you suggest that
>>
>> range(None, 5)
>
> would return the same result as
>>
>> range(5)
>
> But that's simply not how it works.

No, you'd use "range([start=0,] stop, [step=1,] /)" to represent that case.

Remember that this is about representing how the function effectively works
from the user's point of view, not how it actually implements argument
unpacking internally.

Allowing default values and having "=None" implied for optional groups
should cover all the cases we have to handle. If there are exceptions, I'd
prefer to fix them over considering the future introduction of a new
singleton (even if fixing them means offering better ways to handle None in
PyArg_ParseTuple).

> If you want to propose changing the semantics of range, go ahead, I'll
stand back.

Not necessary, it just needs to be possible to express default values.

>
>
>> - a simpler variant that omits the grouping support and only allows
optional parameters on the right should also be reserved
>
>
> If that syntax is a subset of this syntax, and this syntax is reserved,
then by extension we would automatically reserve that syntax too.  In any
other circumstance (this PEP is rejected, the simpler variant uses a
different syntax) the simpler syntax should get a new PEP.
>
> I'll just say that that syntax is insufficient to implement existing
functions we all know and love (addch, range).

Allowing a single optional parameter on the left is enough to handle range,
though.

>> - explicitly delegate to the argument clinic PEP for the impact on
inspect.Signature
>
>
> I'd actually rather do it the other way 'round.  This PEP is a better
place for it.  Even though I think the Clinic PEP has a higher chance of
being accepted ;-)

I thought the group attribute idea was already in the argument clinic PEP.
Since it isn't, documenting it here is fine.

Cheers,
Nick.

>
>
> /arry
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131010/0ba006e7/attachment.html>


More information about the Python-Dev mailing list