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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4