[Python-Dev] PEP 457: Syntax For Positional-Only Parameters (original) (raw)

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