Does Python have Class methods
aleaxit at yahoo.com
Wed May 9 23:39:18 CEST 2001
"Magnus Lie Hetland" <mlh at idi.ntnu.no> wrote in message
news:9dc33k$o0o$1 at tyfon.itea.ntnu.no...
> > > The standard answer is to put the class (e.g. "foo") into its own
> > > (e.g. "foo.py") and use module-level functions.
> > Right, but that supports "static methods" a la C++ rather than "class
> > methods" a la Smalltalk. Another alternative for "static methods" is at
> > http://aspn.activestate.com/ASPN/Python/Cookbook/Recipe/52304, for
> > example. Thomas Heller has also put up a Cookbook recipe, at
> > http://aspn.activestate.com/ASPN/Python/Cookbook/Recipe/52311,
> > which exemplifies how to support "real" (Smalltalk-ish) class methods.
> This is all very fancy and nice, but what is wrong with the following?
> def double(self, x):
> return x*2
> class Doubler:
> double = double
> d = Doubler()
> # returns 6
Having to instantiate a class, to create an instance that has no reason
for existing, just to be able to use that instance for a call that should
not need it except for an artificial limitation...? Seems plenty wrong
enough to me:-).
Say that I have a class whose objects are meant to play substantial
roles and cost some initialization time. DBConnection, for example.
Shall I pay the overhead of starting up a RDBMS and connect to it,
have to provide dbname/username/password for the instantiation,
tear it down the connection when done (or keep encumbering the
RDBMS with a useless connection), so I can call on an _instance_
something that could care less about that instance? Or shall I
contort my class design to add a special way to call __init__ that
builds a skeleton-instance with a special flag -- test that flag in
every real method to raise an exception if the method is ever
called on a skeleton-instance -- to avoid the overhead...?
Module functions, callable wrappers, etc, all seem preferable to
me in the general case, to making a class method a fake instance
method instead. There may be exceptions when the class IS
very light to instantiate, I guess, but that forces client-code to
know what approach is used on each given class.
> I remember a discussion earlier on (some years ago) about class variables
> where I made a similar remark and someone explained the error of my ways.
> Since replying to Alex's posts usually makes me look foolish, I
> eagerly await the reply <wink>
I don't think there's anything foolish in your question here -- the
distinction between class objects and instance objects IS deep
enough to be well worth meditating about!-)
More information about the Python-list