why is there no class (static) methods in Python ?

James_Althoff at i2.com James_Althoff at i2.com
Mon Jun 18 16:59:43 EDT 2001


D-Man wrote:
>On Mon, Jun 18, 2001 at 12:21:53PM -0700, James_Althoff at i2.com wrote:
><...>
>| I notice that yourModule.yourFunction1
>| is exactly what I want, but I need to override yourModule.yourFunction2
in
>| order to adapt it for myModule.MyClass.  How can I do this (preferably
>| WITHOUT resorting to "black magic" and whilst preserving
>| "thread-safeness")?
>
>#### myModule.py
>
>import yourModule
>
>myFunction1 = yourModule.yourFunction1
>
>def myFunction2( ) :
>    pass

Except that this doesn't work (which is the whole point! :-)  ).

#### module testcm1

def function1():
    function2()

def function2():
    print 'testcm1.function2'

#### module testcm2

import testcm1

function1 = testcm1.function1

def function2( ) :
    print 'testcm2.function2'

#### test run

C:\>python
Python 2.0b1 (#4, Sep  7 2000, 02:40:55) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import testcm1
>>> import testcm2
>>> testcm1.function1()
testcm1.function2
>>> testcm2.function1()
testcm1.function2
>>>

In both cases the "original" function2 is being called and the "new"
function2 is never invoked.  This is because "function1 =
testcm1.function1" is just creating a new variable that points to the
origina function.  It doesn't change the implementation of that function in
any way.

>
>| I am stuck -- because module functions are NOT methods (in the sense
that
>| they are not associated with an instance) and hence do not participate
in a
>| "method lookup/override" mechanism.  So if I define my own
>
>As Alex Martelli has demonstrated a few times, you can substitute a
>class instance that implements __setattr__ and __getattr__ in place of
>the module object in sys.modules.

How would such an approach work with "import", "from", "__import__", etc.?
Is it really viable to try to create a class whose instances "fake" module
objects?  And use this as the standard idiom for modules?

>
>| So true class methods -- methods invoked on class objects with
inheritance
>| and override (a la Smalltalk) -- are good -- and far better than module
>| functions acting as a poor man's substitute therein -- mainly if you
>| consider code extensibility and reuse a good thing.
>
>Maybe the new meta class stuff will help with this?  (I don't know)

My own metaclass experiments and posts have all tried to provide a
mechanism for true class methods.  But all metaclass mechanisms in Python
that I'm familiar with are awkward, IMHO -- and probably don't and won't
get used much (if at all).  As far as the class/type healing work that is
underway: I hope class methods will be a part of it.  But so far the
messages from Guido that I've seen indicate that though the class/type
healing is a high priority, true class methods as a part of said healing
are not necessarily important (to him).  So I'm not optimistic.

>
>-D

Jim







More information about the Python-list mailing list