An alternative approach to bound methods
jpet at eskimo.com
Sun Feb 25 21:34:56 CET 2001
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...
> > > 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:
>>> c = C()
Traceback (innermost last):
File "<pyshell#5>", line 1, in ?
File "<pyshell#3>", line 3, in spam
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
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)
More information about the Python-list