On Mar 3, 2014, at 22:02, David Townshend email@example.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`
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...
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.