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

Steven D'Aprano steve at pearwood.info
Tue Mar 4 12:09:21 CET 2014


On Mon, Mar 03, 2014 at 11:03:03PM -0800, Andrew Barnert 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'

Off the top of my head, I think that looks alright.


> >     thunk(x=2)

I'm not entirely sure about that. That basically makes these thunks just 
a function. I'm still not quite sure how this should actually be used in 
practice, so as far as I'm concerned this is just pie in the sky 
thinking aloud. If thunks are just functions, why not make them 
functions? There needs to be something extra (different scoping rules, 
faster/more lightweight, *something*) to make the idea worthwhile.

I think I need to learn more about Algol and other languages that use 
call-by-name and thunks. I may be completely on a wild-goose chase here, 
but I'm surely not the only person who has needed to delay evaluation of 
an expression.

http://en.wikipedia.org/wiki/Thunk


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

Actually I'd be happy with backticks, but Guido has said No Backticks 
Ever Again. So until the Glorious Revolution, we're stuck.


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

Agreed. What I have in my head is some vague concept that the Python 
evaluation rules will somehow know when to evaluate the thunk and when 
to treat it as an object, which is (as I understand it) what happens in 
Algol. Again, just thinking aloud, perhaps we do this:

thunk = `some_expression`  # delays evaluation
a = [0, 1 + thunk]  # evaluates thunk in the current scope
b = [0, `1 + thunk`]  # delays evaluation and creates a thunk object
                      # equivalent to `1 + some_expression`
c = b[1]  # now evaluates the thunk object
d = f(2, thunk)  # evaluates thunk in f's scope
e = g(3, `thunk`)  # passes the un-evaluated thunk object to g

Consider this just a sketch, and in no way fully thought out.

(This will most definitely need a PEP.)


> > 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 have little interest in allowing thunks to be statements. If you want 
a delayed statement, use compile and eval. Or def. (But maybe that 
applies to expressions too?)

Did I mention this needs a PEP?



-- 
Steven


More information about the Python-ideas mailing list