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

[David Townshend]

On 1 Mar 2014 05:46, "Steven D'Aprano" <steve at pearwood.info> wrote:
>
> 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)

What about a new code literal object, e.g.

    thunk = c'x + 3'
    thunk(x=2)

The "c" prefix identifies the literal as an code so highlighters can
recognise it and it can be parsed. Triple quotes could also be used to
support multiline code blocks.  It would also be possible to prohibit any
direct conversion from a string to avoid the security problems. I'm not
sure how positional arguments would be handled though, and scoping still
needs to be thought through.

>
> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140304/741cac8a/attachment-0001.html>