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

Benjamin Peterson benjamin at python.org
Wed Oct 9 16:24:06 CEST 2013

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

More information about the Python-Dev mailing list