Unification of Methods and Functions

[David MacQuigg]

On Tue, 11 May 2004 18:10:36 +1000, "Delaney, Timothy C (Timothy)"
<tdelaney at avaya.com> wrote:

>Antoon Pardon wrote:
>
>> I'm a bit sick of this argument. There is a lot om implicity
>> going on in python. if obj belongs to cls then obj.method()
>> is syntactic sugar for cls.method(obj). That looks like
>> a big implicite way to handle things in python.

<snip examples>
>Yes - there is a lot hidden here - but what is hidden is purely
>implementation details.

It should never bother the user, right?

Pop Quiz:
Which of the four outputs below is possible. Hints: Add a statement or
two in front of these commands, then test your assumptions by running
the sequence in your Python interpreter.

>>> cat2 = cat1()
>>> Cat.f = cat1.func
>>> cat1.f = Cat.func
>>> Cat.func, Cat.f, cat1.func, cat1.f
A)
(<unbound method Cat.func>, <function func at 0x00A89530>, <function
func at 0x00A89530>, <unbound method Cat.func>)
B)
(<function meth at 0x00A89530>, <unbound method cat1.meth>, <bound
method cat1.func of <__main__.cat1 instance at 0x00A5A5F8>>, <unbound
method cat1.meth>)
C)
(<function meth at 0x00A89530>, <unbound method cat1.meth>, <unbound
method cat1.meth>, <unbound method cat1.meth>)
D)
(<unbound method Cat.func>, <unbound method Cat.f>, <bound method
cat1.func of <__main__.cat1 instance at 0x00A5A5F8>>, <bound method
cat1.f of <__main__.cat1 instance at 0x00A5A5F8>>)

In spite of all this, I still favor Python's implicit binding over the
alternatives I have seen.  To make binding really clear and explicit,
you need to burden some very simple calls like cat1.method1() with
extra syntax.  So we pay a price on edge cases like the above, to make
the normal use easy.

Prothon is trying to make binding explicit, and they have a mess IMHO.
This happens when you treat all possibilities as equally important,
and don't exercise good judgement on what is overall the best
compromise.

-- Dave

The one rule that trumps all others:  Practicality beats purity.