Unification of Methods and Functions

[Antoon Pardon]

Op 2004-05-22, 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?  One thing I
>>like about Python is that there is only function-body syntax and not a
>>separate, slightly different method-body syntax.  To me, having only one
>>type of code body *is* unification.  So it is hard for me to see what is
>>being proposed.  Introducing a syntax like '.var' that would only be
>>meaningful in a method and not a function would be dis-unification.
>
> There seems to be a lot of misunderstanding on the question of "magic"
> in Python's method binding syntax vs the proposed syntax.  I see
> students having difficulty learning the current syntax.  Python
> experts say its real easy, and point to the explicit "self" as an
> advantage of the current syntax, vs the "magic" of setting a global
> __self__ variable.  All of this is missing the problem.
>
> If Python were consistent, and *always* used a special first argument,
> there wouldn't be a problem.  The magic first argument would be no
> more difficult than magically setting a global variable.  The problem
> is that some methods require a magic first argument, and others
> require that it *not* be there.  In one case you call cat1.talk() and
> in another it is Cat.talk(cat1).  I know this is not terribly
> difficult to understand -- one is a bound method, the other unbound.
> Still it is a problem for beginners, and it leads to unecessary
> complexities like static methods.
>
> The recent discussion on "Method binding confusion" 5/2/04 shows that
> even experts can get confused.  Here is the example, reduced to its
> simplest terms:
>
> import math
>
> def mypow(x, y):
>       return x**y
>
> class MathA:
>    pow = math.pow
>
> class MathB:
>    pow = mypow
>
> ma = MathA()
> mb = MathB()
>
> print ma.pow(2,4) #=>
> 16.0
> print mb.pow(2,4) #=>
> # TypeError: mypow() takes exactly 2 arguments (3 given)
>
> How would you explain this to non-CIS students in a class on circuit
> design, where there is very little time to discuss programming?

For as far as it is necessary to explain this, I would explain it as
a bug. IMO this is a bug because the behaviour seems to differ depending
on whether the function is implemented in C or python. Users of a module
shouldn't be concerned how something is implemted.

-- 
Antoon Pardon