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

[Steven D'Aprano]

On Fri, Feb 28, 2014 at 11:17:18AM -0600, Ron Adam wrote:
> 
> Starting new thread because this bike has a different shape and color.
> 
> Yesterday I was thinking that just making the keyword lambda assignable 
> like True, False, and None, would be enough.

You can't assign to True, False or None. (You can assign to True and 
False in Python 2, but shouldn't.)


[...]
> This morning I thought we could have in a functions definition something, 
> like "*", and "**", to take an expression.  Similar to Nicks idea with =:, 
> but more general.
> 
> The idea is to have "***" used in def mean to take "any" call expression 
> and not evaluate it until *** is used on it.
[...]
> A function call that captures an expression may be tricky to do. Here's one 
> approach that requires sugar when a function defined with "***" is called.

I think it would be useful to have a way to delay execution of an 
expression, that is to say, have a way to capture an expression for 
later evaluation, something more lightweight than a function, but I 
don't think that limiting it to inside function calls is the right 
approach.

Something perhaps like a thunk might be appropriate? We can *almost* do 
that now, since Python has a compile function:

thunk = compile("x + 3", "", "eval")
# much later
eval(thunk)

Some problems with that approach:

- You have to write the expression as a string, which means you lose any 
possibility of syntax highlighting.

- The temptation is to pass some arbitrary untrusted string, which leads 
to serious security implications. The argument here should be limited 
to an actual expression, not a string containing an expression which 
might have come from who knows where.

- It should be as lightweight as possible. The actual compilation of the 
expression should occur at compile-time, not run-time. That implies some 
sort of syntax for making thunks, rather than a function call.

- Likewise actually evaluating the thunk should be really lightweight, 
which may rule out a function call to eval.

- How should scoping work? I can see use-cases for flat scoping, static 
scoping, dynamic scoping, and the ability to optionally provide custom 
globals and locals, but I have no idea how practical any of them would 
be or what syntax they should use.


All of this is pie-in-the-sky at the moment, and not a serious proposal 
for Python 3.5.


-- 
Steven