An alternative approach to bound methods

[Jeff Petkau]

Alex Martelli <aleaxit at yahoo.com> wrote in message
news:978t7802ghb at news1.newsguy.com...
> "Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote in message
> news:slrn99ffp6.ep3.qrczak at qrnik.zagroda...
>     [snip]
> > > People will often and erroneously make recursive calls to
> > > "amethod(a,b,c)" when they should be going through self, because
> > > "going through self" IS the normal, most frequently desired case.
> >
> > Both are equally easy. Why would anybody write
> >     amethod(self,b,c)
> > instead of
> >     self.amethod(b,c)
> > when he means the latter?
>
> [...]
> The key point is that we need to keep diagnosing this error
> at runtime clearly and unambiguously, just like Python does
> now -- this is and will remain an important pragmatical issue,
> and pragmaticity trumps purity.
>
> > > I don't want this error to become a silent, mysterious one; we know
> > > have clear diagnostics for it, and losing them would be a serious
> > > step backwards.

Unbound methods don't get involved in this error message anyway--
the name lookup fails.

>>> class C:
        def spam(self):
            spam(self)

>>> c = C()
>>> c.spam()
Traceback (innermost last):
  File "<pyshell#5>", line 1, in ?
    c.spam()
  File "<pyshell#3>", line 3, in spam
    spam(self)
NameError: There is no variable named 'spam'
>>>

I can't really see any use whatsoever for unbound method
objects. The only effect they have is to make class
methods not work, by adding a typecheck that makes
unwarranted assumptions about what the first parameter
should be.

The semantics could also be a little simpler if they went
away. If you put something in a class, you get the same
object out. If you put something in an instance, you get
the same object out. If you put something in a class and
retrieve it through the instance, *then* it would add the
magic 'self' parameter.

--Jeff Petkau (jpet at eskimo.com)