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

[Larry Hastings]

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.


> 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.


> 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.

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.


//arr//y/

* The callable is not simply curses.window.addch; window is a class or 
something.  But addch is definitely a callable you can get your hands on 
in Python.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131009/b067e08c/attachment.html>