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

David Townshend aquavitae69 at gmail.com
Tue Mar 4 10:03:35 CET 2014


On Tue, Mar 4, 2014 at 9:03 AM, Andrew Barnert <abarnert at yahoo.com> wrote:

> 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`
>
>
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140304/9c2a877f/attachment.html>


More information about the Python-ideas mailing list