2013/10/9 Larry Hastings <la...@hastings.org>: > > On 10/09/2013 03:31 AM, Benjamin Peterson wrote: > > 2013/10/8 Larry Hastings <la...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
