An alternative approach to bound methods
Marcin 'Qrczak' Kowalczyk
qrczak at knm.org.pl
Sat Feb 24 15:03:18 CET 2001
Fri, 23 Feb 2001 12:33:00 +0100, Alex Martelli <aleaxit at yahoo.com> pisze:
> class Aclass:
> def amethod(x, *args):
> # body snipped
> is this 'amethod' a "class method" or an "instance method"?
> Does calling it via
> or via
> change anything?
> > Are you asking about the semantics of a particular piece of code?
> > If so, which code? My proposal is unambiguous.
> And it does unambiguously mean that mentioning 'amethod' within
> the above amethod's code body will in fact refer to Aclass.amethod,
> not self.amethod, then?
> 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
when he means the latter?
> And this is checked at runtime, and gives a very clear
> error message if the user makes a mistake about it:
> TypeError: unbound method must be called with class instance 1st argument
It's not necessarily a mistake.
> class Derived(Base):
> def foo(self, *args):
> print "Derived.foo",args
> 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.
I admit that this error would have a worse diagnostics (usually:
too few arguments, i.e. not that bad). The same can be said about
writing 'self' in method definitions: when one forgets it, the error
is equally mysterious.
__("< Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
^^ SYGNATURA ZASTĘPCZA
More information about the Python-list