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

Ron Adam ron3200 at gmail.com
Sat Mar 1 05:07:27 CET 2014



On 02/28/2014 08:14 PM, Chris Angelico wrote:
> On Sat, Mar 1, 2014 at 6:42 AM, Ron Adam <ron3200 at gmail.com> wrote:
>> It's not clear what differences you mean here... can you show some examples?
>
> These are exactly the same:
>
> x = (1,2)
> f(*x)
 >
> f(1,2)
 >
> I played with dis.dis() and it seems there are special-case opcodes
> for calling a function with a variable number of arguments and/or with
> variable keyword args; but once it arrives at the other side, the two
> are identical:
>
>>>> def f(*args):
>      print(args)
>>>> f(1,2)
> (1, 2)
>>>> x=(1,2)
>>>> f(*x)
> (1, 2)
>
> The runtime fetches some callable, gives it some args, and says "Go do
> your stuff!". It doesn't care what that callable is - it could be a
> classic function defined with 'def' or 'lambda', it could be a type,
> it could be an object with __call__, it could be a built-in that's
> backed by a C function, anything. All that ends up arriving on the
> other side is: You have these positional args and these keyword args.
>
> Adding the tri-star to the mix suddenly changes that. A function is
> now capable of taking an expression, rather than an object. That's
> completely different, and it depends on the called function to
> distinguish one from the other.

Right..  To make it work in the way I was thinking would require each 
function consisting of two parts.  One part to build a name-space, and the 
other for executing the code.  Then at call time, the first part could 
evaluate the expressions inside the function parentheses. This part would 
be new, and possibly work like a dict comprehension, except more specific 
to call signatures.  Then the constructed name space would be passed 
directly to the code part for the actual call.  Which would be quite 
different than what happens presently.


I've refactored dis once for fun, and also played around with ceval enough 
to know how this stuff works, but when I haven't looked at the code 
recently,  (like now) I tend to think more in abstract terms which helps 
with creativity and seeing new ways to do things.  (And it is why I like 
reading this list), But I sometimes misses on the objectivity side... [Note 
to self... look at the code more.]

It comes down to this...

    "Creativity and Objectivity often don't want
     to occupy the same space at the same time."
also helped test some patches to dis as well.  And
Cheers,
    Ron



More information about the Python-ideas mailing list