[Python-Dev] Rough idea for adding introspection information for builtins (original) (raw)

Larry Hastings larry at hastings.org
Tue Mar 19 10:24:53 CET 2013

On 03/19/2013 12:37 AM, Serhiy Storchaka wrote:

On 19.03.13 06:45, Larry Hastings wrote:

4. Store a string that looks like the Python declaration of the signature, and parse it (Nick's suggestion). For foo above, this would be "(arg,b=3,*,kwonly='a')". Length: 23 bytes. Strip parenthesis and it will be only 21 bytes long.

I left the parentheses there because the return annotation is outside them. If we strip the parentheses, I would have to restore them, and if there was a return annotation I would have to parse the string to know where to put it, because there could be arbitrary Python rvalues on either side of it with quotes and everything, and now I can no longer use ast.parse because it's not legal Python because the parentheses are missing ;-)

We could omit the /left/ parenthesis and save one byte per builtin. I honestly don't know how many builtins there are, but my guess is one extra byte per builtin isn't a big deal. Let's leave it in for readability's sakes.

We'd want one more mild hack: the DSL will support positional parameters, and inspect.Signature supports positional parameters, so it'd be nice to render that information. But we can't represent that in Python syntax (or at least not yet!), so we can't let ast.parse see it. My suggestion: run it through ast.parse, and if it throws a SyntaxError see if the problem was a slash. If it was, remove the slash, reprocess through ast.parse, and remember that all parameters are positional-only (and barf if there are kwonly, args, or kwargs). It will be simpler to use some one-character separator which shouldn't be used unquoted in the signature. I.e. LF.

I had trouble understanding what you're suggesting. What I think you're saying is, "normally these generated strings won't have LF in them. So let's use LF as a harmless extra character that means 'this is a positional-only signature'."

At one point Guido suggested / as syntax for exactly this case. And while the LF approach is simpler programmatically, removing the slash and reparsing isn't terribly complicated; this part will be in Python, after all. Meanwhile, I suggest that for human readability the slash is way more obvious--having a LF in the string mean this is awfully subtle.

//arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130319/cd544da1/attachment.html>

More information about the Python-Dev mailing list