On Tue, Mar 4, 2014 at 9:03 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Mar 3, 2014, at 22:02, David Townshend <aquavitae69@gmail.com> wrote:

What about a new code literal object, e.g.

    thunk = c'x + 3'
    thunk(x=2)

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.

Not that I'm seriously suggesting backticks here, but...

    thunk = `x + 3`


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.
 
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.

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...

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.

Triple quotes could also be used to support multiline code blocks.

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.

I'm not sure how positional arguments would be handled though, and scoping still needs to be thought through.

If you have a code object, scoping is up to whoever evaluates it or builds a function out of it.