Decorator Dissection

[Ron_Adam]

On Sun, 03 Apr 2005 08:32:09 +0200, "Martin v. Löwis"
<martin at v.loewis.de> wrote:

>Ron_Adam wrote:
>> I wasn't aware that the form:
>> 
>> 	result = function(args)(args)
>> 
>> Was a legal python statement.
>> 
>> So python has a built in mechanism for passing multiple argument sets
>> to nested defined functions! (click)  Which means this is a decorator
>> without the decorator syntax.
>
>No. There is no mechanism for passing multiple argument sets to
>nested functions. Instead, functions are objects, which can be
>assigned to variables, passed as arguments to other functions,
>and returned:

Yes there is, it's the stack python uses to interpret the byte code.
But it's the same mechanism that is used for passing arguments to
sequential function calls (objects) also.  The only difference is the
next function (object) is returned on the stack in the nested case.
Then the next argument is then put on to the stack (passed), before
the next function is called.  

How you view this depends on the frame of reference you use, I was
using a different frame of reference, which I wasn't sure was correct
at the time, but turns out is also valid.  So both view points are
valid. 

In any case, I now have a complete picture of how it works. Inside,
and out. Which was my goal.  :)

>> So this isn't a decorator question any more.  Each argument gets
>> passed to the next inner defined function,  via... a stack(?)  ;)
>
>No, functions are objects. Notice that in step 1, the object returned
>doesn't have to be a function - other things are callable, too, like
>types, classes, and objects implementing __call__.

They are objects; which are data structures; containing program code &
data; which reside in memory; and get executed by, in this case, a
byte code interpreter.  The interpreter executes the byte code in a
sequential manner, using a *stack* to call functions (objects), along
with their arguments.

For the record, I never had any trouble understanding the concept of
objects. I think I first started programming OOP in the mid '90's with
c++.

It was the sequence of events in the objects of the nested def
functions that I was trying to understand along with where the objects
get their arguments, which isn't obvious because of the levels of
indirect calling.

Thanks for the help Martin, it's always appreciated.  :)

Cheers,
Ron


>Regards,
>Martin