Method binding confusion

[Antoon Pardon]

Op 2004-05-22, David MacQuigg schreef <dmq at gain.com>:
> On Mon, 03 May 2004 19:52:02 +0200, Peter Otten <__peter__ at web.de>
> wrote:
><snip>
>>The machinery behind the observed behaviour is now somewhat clearer - I
>>think you can predict a function's behaviour as a method by checking
>>hasattr(func, "__get__"). But still the *reason* (or simply use-case) for
>>this dichotomy of functions (to me) remains unclear. Why are not all
>>functions created equal?
>
> All functions and methods *should* be unified.  See the section
> "Unification of all function forms" in PrototypeSyntax.doc at
> http://www.ece.arizona.edu/~edatools/Python
>
> I'm astonished at how a problem like this can be tolerated in a
> language that claims to be simple.
>
> Here is my simplification of the example which started this thread:
>
> 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)
>
> This problem, and a lot of others that confuse beginners could be
> eliminated if all functions and methods had exactly the same sequence
> of arguments (no special first argument).

I agree that what you show here is a problem, because the behaviour of
the language here is not consistent.

However I get the impression that a lot of confusion you see with
beginners is your own confusion you are passing on.

-- 
Antoon Pardon