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