Unification of Methods and Functions

[David MacQuigg]

On 14 May 2004 12:29:32 GMT, Antoon Pardon <apardon at forel.vub.ac.be>
wrote:
>Op 2004-05-13, David MacQuigg schreef <dmq at gain.com>:
>> On Thu, 13 May 2004 10:56:58 -0400, "Terry Reedy" <tjreedy at udel.edu>
>> wrote:
>>>"Antoon Pardon" <apardon at forel.vub.ac.be> wrote in message
>>>news:slrnca6d58.1i9.apardon at trout.vub.ac.be...
>>>> One could argue that all forms of methods and functions are unified.
>>>> It is just that python does some magic so that the method you
>>>> access from an object is not the actual function but the curried
>>>> function with the object.
>>>
>>>My view is similar: in Python, a method is a dressed up (wrapped) function.
>>>'Unification of methods and functions' reads to me like 'unification of
>>>dressed-up bodies and naked bodies'.  What would that mean?  
>>
>> By unification, I mean making the calling sequence identical for all
>> methods and functions.
>
>It already is. It is just that the function you have defined within
>the class, is not the function you call through the object.

In the current sytnax, we need a special "staticmethod" statement to
define a method we can call without an instance.  In the proposed
syntax, there is no distinction between the different method styles,
and no need for special syntax.  A "staticmethod" has the same
arguments as normal method, and the same as an ordinary function.
This is what I mean by having the same "calling sequence".

For an example of how unification simplifies the presentation of OOP,
see the first 8 pages of
http://ece.arizona.edu/~edatools/Python/Prototypes.doc

>> The choice of how to identify instance variables is a minor issue.  I
>> think it is actually better not to *hide* the instance variables, but
>> to *highlight* them.  Ruby uses $var for instance variables.  Prothon
>> uses a leading dot, which is quite visible in most code editors.
>>
>> The real issue is not self.var vs .var  It is the complexity resulting
>> from having different calling sequences.
>
>There really aren't different calling sequences, just to different
>related function.

In the Animals.py example at http://ece.arizona.edu/~edatools/Python/
there is a method Mammal.show().  Normally, the calling sequence is
Mammal.show(cat1)
where cat1 is just an instance needed to satisfy the requirement for a
special first argument.  The method does not *use* cat1, and in
general, there may not be an instance of every class available. If we
convert Mammal.show to a static method, we don't need the special
first argument.  The calling sequence is then
Mammal.show()

Do you understand what I mean by "different calling sequences"?

<snip>

>Having __self__ being
>a global variable is disaster waiting to happen. What if a method
>calls another method, what if you use threads?

If a method calls another method, the same thing happens in the
proposed syntax as in current Python.  Normally, the current instance
doesn't change.
Python 2>>> Mammal.talk(self)
Python 3>>> Mammal.talk()
If you want to *over-ride* the normal behavior and *force* a specific
binding:
Python 2>>> Mammal.talk(cat2)
Python 3>>> __self__ = cat2; Mammal.talk()
I don't know why anyone would ever want to do this within a method,
but it is possible.

I don't understand the problem with threads.  Perhaps an example would
help.

-- Dave