[Python-ideas] One more time... lambda function <--- from *** signature def.

[Andrew Barnert]

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140303/553d0281/attachment.html>