[Python-Dev] Rough idea for adding introspection information for builtins
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
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
>> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev