Does Python have Class methods

[Alex Martelli]

"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
module
> > > (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()
>   d.double(3)
>   # 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!-)


Alex