<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 4, 2014 at 9:03 AM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div class=""><div>On Mar 3, 2014, at 22:02, David Townshend <<a href="mailto:aquavitae69@gmail.com" target="_blank">aquavitae69@gmail.com</a>> wrote:</div>

<blockquote type="cite"><p dir="ltr">What about a new code literal object, e.g.</p>
<p dir="ltr">    thunk = c'x + 3'<br>
    thunk(x=2)</p></blockquote></div><div>Why does it need to be built from/look like a string? I think it would be just as simple for the parser, and simpler for editors, and less misleading for readers, if it used a different marker.</div>

<div><br></div><div>Not that I'm seriously suggesting backticks here, but...</div><div><br></div><div>    thunk = `x + 3`</div><div><br></div></div></blockquote><div><br></div><div>The only real reason for it looking like a string is a shortage of symbols.  Backticks are off limits, and most other symbols are just plain ugly (e.g. @x + 3@ or $x + 3$) or already in use in a way that could lead to ambiguity (e.g. |x + 3|).  String-like quotes seem like a better option than the alternatives.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>Most existing editors already treat that as an expression (since in 2.x it means repr(x + 3)). No human reader is going to be misled into thinking this means there's a way to create code objects from string objects without eval (c.f. all those questions on StackOverflow about how to make a raw string from a string...). And as far as the parser is concerned, it's trivial: '`' expr '`' is a Code whose value is whatever expr parses to.</div>

<div><br></div><div>Meanwhile, if this gives you a code object, what do you do with it? Using eval on something that looks like a string but isn't may be correct to anyone who understands Python deeply, but I think it could be very misleading to anyone else. And creating a FunctionType from a code object is pretty ugly for something that deserved literal support...</div>

</div></blockquote><div><br></div><div>My suggestion was to use c'x + 3' as an effective replacement for compile('x + 3', '', 'eval').  The use of a literal rather than compile would solve a few of the issues raised in Steven's original post.  I don't see why it would be any more misleading to eval a code literal than a compiled string.  I did suggest making it callable (i.e. thunk(x=3), but on second thoughts I'm not sure that's a good idea.  It adds complexity without and real benefit over eval.<br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div class=""><blockquote type="cite">
<p dir="ltr">Triple quotes could also be used to support multiline code blocks.</p></blockquote></div><div>That is one advantage of reusing strings. In fact, that gives us a way to embed statements in the middle of expressions. Which I'm not sure is a good thing.</div>

<div class=""><blockquote type="cite"><p dir="ltr">I'm not sure how positional arguments would be handled though, and scoping still needs to be thought through.</p></blockquote></div><div>If you have a code object, scoping is up to whoever evaluates it or builds a function out of it.</div>

</div></blockquote></div><br></div></div>