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

[Ron Adam]

On 02/28/2014 04:33 PM, Nick Coghlan wrote:
> On 1 Mar 2014 05:43, "Ron Adam"
> <ron3200 at gmail.com
> <mailto:ron3200 at gmail.com>> wrote:
>  >
>  >
>  >
>  > On 02/28/2014 11:54 AM, Chris Angelico wrote:
>  >>
>  >> On Sat, Mar 1, 2014 at 4:17 AM, Ron
> Adam<ron3200 at gmail.com
> <mailto:ron3200 at gmail.com>>  wrote:
>  >>>
>  >>> >This returns a lambda-like function.
>  >>> >
>  >>> >       def star_lambda(***expr): return expr
>  >>> >
>  >>> >
>  >>> >And is used this way...
>  >>> >
>  >>> >       result = star_lambda(a * b + c)  # captures expression.
>  >>> >
>  >>> >       actual_result = ***result        # *** resolves "result" here!
>  >>> >
>  >>
>  >> Interesting, but I don't like the way the interpretation of a function
>  >> call depends on the target function. With both * and ** notations,
>  >> there's absolutely no difference: the function is called with these
>  >> positional and those keyword arguments, whether they came from actual
>  >> args or from * or ** unpack/repacks;and there's no difference between
>  >
>  > > a function that collects args with *args,**kwargs and one that
>  > > collects them with individual names (or a C-level function that might
>  > > do something altogether different).
>  >
>  >
>  > It's not clear what differences you mean here... can you show some examples?
>
> Remember that at compile time, Python has *no idea* what the actual
> signature of the target function is. Thus, all Python function calls use
> the following sequence (ignoring optimisations of special cases):
>
> 1. At the call site, the arguments are collected into a tuple of positional
> arguments and a dict of keyword arguments.
> 2. The interpreter hands that tuple and dict over to the target callable
> 3. The *target callable* then maps the supplied arguments to the defined
> parameters including filling in any default values.
>
> Any function related proposals need to account for the fact that from the
> compiler's point of view *every* function signature looks like "(*args,
> **kwds)" (although it may have optimised paths for the no-args case and the
> positional-args-only case), and that the target callable may not even be
> written in Python.

So functions can't be extended to take a triplet instead of a pair...

       (*args, **kwds, ***expr)


Looking up...  I think this is what you're referring to in ceval.c.

#-------------------

/* External interface to call any callable object.
    The arg must be a tuple or NULL.  The kw must be a dict or NULL. */

PyObject *
PyEval_CallObjectWithKeywords(PyObject *func, PyObject *arg, PyObject *kw)
{

#--------------------

And it wouldn't work in the normal case any way, as expressions are 
evaluated as they are put on the stack before calling the function.

Somehow I was thinking this morning the code inside the function call 
parentheses f(...), could be parsed later than it actually is.  And in the 
context of the function definition, possibly similar to how a comprehension 
is evaluated.  But it would take some pretty big changes to do that I supose.

Cheers,
    Ron