[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