[Python-Dev] Rough idea for adding introspection information for builtins

[Larry Hastings]

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>