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

[Benjamin Peterson]

2013/10/9 Larry Hastings <larry at hastings.org>:
>
> On 10/09/2013 03:31 AM, Benjamin Peterson wrote:
>
> 2013/10/8 Larry Hastings <larry at hastings.org>:
>
> This PEP proposes a backwards-compatible syntax that should
> permit implementing any builtin in pure Python code.
>
> This is rather too strong. You can certainly implement them; you just
> have to implement the argument parsing yourself.
>
>
> Can you suggest an alternative wording?  What I was trying to say was, you
> cannot express many builtin's signatures in pure Python code.  I guess
> "implement" is the bad word here--you can implement those semantics, but you
> cannot express it syntactically.  So how about
>
> This PEP proposes a backwards-compatible syntax that should permit
> expressing the signature of any builtin as a Python function.

That's fine.

>
>
> Python's
> call/signature syntax is already extremely expressive, and resolving
> call arguments to formal parameters is already a complicated (and
> slow) process.
>
>
> Well, I did propose that the syntax not actually be implemented.

Yes, that's good.

>
>
> Implementing functions with such strange argument
> semantics is hardly common enough to justify the whole grouping syntax
> proposed in this PEP. -1 to that. I think I can live with "/", but
> YANGTNI still.
>
>
> On the contrary, I can tell you exactly when I'm going to need it.
>
> What happens when you run "help(foo)"?  pydoc examines the signature of the
> function and generates the first line, the function's prototype.  For
> builtins, pydoc currently sees that there is no introspection information
> and skips the generation, which is why docstrings for builtins by convention
> have a handwritten prototype as their first line.
>
> Let's assume that the Argument Clinic PEP is accepted, and my current
> implementation goes in, and I add introspection metadata for builtins.  Once
> we have this metadata, pydoc will use it and generate that first line for
> builtins itself.
>
> Now: what happens when you run "help(curses.window.addch)"? *
>
> My first problem: Argument Clinic has to allow the core C developer to
> express the signature of addch.  The syntax is Python-like, if you change
> the commas into newlines and enforce a few extra rules regarding leading
> whitespace.  But Python's existing syntax can't communicate the semantics of
> addch.  Nobody fought me on Clinic's need to express this sort of function,
> though I had plenty of bikeshedding on the syntax.  Then Guido dictated a
> syntax at PyCon US 2013, and that was that.
>
> My second problem: I have to communicate the metadata in Argument Clinic's
> output to the CPython runtime.  Almost nobody cares what this looks like, as
> it will be an implementation detail.  But I suspect there will be one or two
> places where you can't use Clinic yet, so you'll be writing this metadata by
> hand.  So it needs to be cogent and human readable.  Barry Warsaw suggested
> that the best syntax--not only most readable, but most compact--was to just
> use Python's own syntax.  Again, existing Python syntax can't communicate
> the semantics of addch.  So I expect to use this syntax for the metadata of
> builtins.
>
> My third problem: I have to represent the signature of these functions with
> inspect.Signature.  Parameter objects can be marked as having a "kind" of
> inspect.Parameter.POSITIONAL_ONLY, so inspect has at least tacit, vestigial
> support for positional-only parameters.  In practice this is insufficient to
> express the semantics of addch.  IIRC Brett said I could add a "group" field
> to inspect.Parameter indicating the "option group" of a parameter.  (There's
> no way I'm modifying inspect.getargspec() or inspect.getfullargspec() to
> represent positional-only parameters.)
>
> My fourth problem: I have to modify pydoc so it uses inspect.signature()
> instead of inspect.getfullargspec(), then understands the new semantics of
> positional-only parameters.  And then it needs to generate that first line.
> But what should that line look like--what should be its syntax?  It's
> written in Python syntax, but Python existing syntax can't communicate the
> semantics of addch.  So I expect to use this syntax for the first line
> generated by pydoc.
>
> And there you have it.  I have to represent the semantics of addch in four
> places, and three of those are textual.  Two are implementation details, but
> in practice they will use Python syntax.  The third is documentation but
> should also be Python syntax.
>
>
> My goal with the PEP is to codify existing practice.  I find it a bit
> perverse that we have functions callable in Python with call signatures one
> cannot express syntactically in Python, and with undocumented semantics
> (their parameters are positional-only but this is not mentioned).  I
> understand it's all kind of a historical accident, but it is absolutely part
> of Python and it's not going away.

You can express any wild argument semantics you want in Python with
*args and **kwargs. If the "strange" C functions like range() and
addch() get signature objects, I don't think it's the end of world if
it looks like a Python *args, **kwargs signature.

>
> My proposed syntax is a little complex--but complex is better than
> complicated and inconsistent and undocumented and inconvenient, which is
> what we have now.

Certainly the argument conventions of these functions are not
undocumented, so wonder what is. Also, inconvenient for what? What
inconsistency problem does this PEP solve?



-- 
Regards,
Benjamin