On Sun, 03 Apr 2005 23:59:51 +0200, "Martin v. Löwis"
<[EMAIL PROTECTED]> wrote:
>Ron_Adam wrote:
>> This would be the same without the nesting:
>>
>> def foo(xx):
>> global x
>> x = xx
>> return fee
>>
>> def fee(y):
>> global x
>> return y*x
>>
>> z = foo(2)(6)
>
>Actually, it wouldn't.
Ok, yes, besides the globals, but I figured that part is obvious so I
didn't feel I needed to mention it. The function call works the same
even though they are not nested functions.
>>
>> It's not entirely a misconception. Lets see where this goes...
>>
>>
>>>>>>dis.dis(compiler.compile('foo(2)(6)','','eval'))
>>>
>>> 1 0 LOAD_NAME 0 (foo)
>>> 3 LOAD_CONST 1 (2)
>>> 6 CALL_FUNCTION 1
>>> 9 LOAD_CONST 2 (6)
>>> 12 CALL_FUNCTION 1
>>> 15 RETURN_VALUE
>
>Hmm. If you think that this proves that (2)(6) is being *passed*, you
>still might have a misconception. What this really does is:
I didn't say they were passed at the same time by the stack. It just
shows my reference to *stacks* was correct, and that there's is an
underlying mechanism for calling functions and passing arguments and
functions that use the stack. I however was not yet aware (yesterday
afternoon) of just how the stack worked in this case. This was very
much a figure it out as you go exercise.
Yesterday, I had made the incorrect judgement that since the functions
are all nested inside a defined function, that I should treat them as
a group instead of individual functions. But that wasn't the correct
way of viewing it. They are in a group in that they share name space,
so I figured, (incorectly), that they shared an argument list somehow,
and those where passed to the group. The passing of the function, and
it's arguments silently was a big reason for me jumping to this
conclusion.
So my reference to:
>>The interesting thing about this is the 'return fee' statement gets
>>the (6) apparently appended to it. So it becomes 'return fee(6).
Which is not correct, as the order of events is wrong and they do not
share a common argument list.
The correct order is:
return fee
fee(6)
with the fee(6) being evaluated after the return statement is
executed.
Another contributing factor is two days of really poor sleep. Which
probably is a bigger factor than I would like to admit. I really feel
I should have gotten it much sooner. But I did get-it, a little bit
at a time, and had a lot of terrific help along the way. :-)
<clip>
>> Or it could be said equally the functions (objects) are passed with
>> the stack. So both view are correct depending on the view point that
>> is chosen.
>
>Maybe I don't understand your view, when you said
>
># No, I did not know that you could pass multiple sets of arguments to
># nested defined functions in that manner.
My views have changed as I added the missing peices to the puzzle
yesterday.
At first I didn't see how they were passed at all, in a group or
otherwise. There wasn't any one-to-one way to match the arguments up
visually like there are in a normal function call.
My next thought was they are passed as a group, to the group of
defined functions that shared the same name space. (Everyone seems to
think I'm stuck on this one.)
My Next view, yesterday afternoon, was they were passed on a stack
somehow one at a time. This last one is not necessarily incorrect from
a byte code viewpoint, but it's not the best way to view the problem.
Today I believe I have the correct view as I've said this morning. I
could be wrong yet again. I hope not though I might have to give up
programming. :/
It's interesting that I have had several others tell me they had
trouble with this too.
So it is my opinion that decorators are a little too implicit. I
think there should be a way to make them easier to use while achieving
the same objective and use.
Thanks again for the reply, :)
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
