[Tutor] class/type methods/functions

[spir]

Hello,

New to the list. I'm a self-taught, amateur programmer. Also, non-native 
english speaker -- so, don't be surprised with weird expression.

Q: Is there a way to write /type/ (class) functions, meaning methods not 
bound to an instance, in python?

Context: I'm developping an application that should be able to 
read/write wiki source text and matching xhtml docs (and more...). 
Actually, a first version worked, but I'm refactoring it for several 
reasons. To do that, I use a core set of 'symbol' types:
wiki lang1
wiki lang2 ==> config ==> symbol types <== xhtml subset
wiki lang3
Each type holds relevant config data and is defines methods used to cope 
with r/w processes. Each symbol holds relevant data, read from 
(whichever) source text, and is able to write itself into (any) target 
language. A sequence of symbols thus builds a kind of abstract 
representation of a source text:
wiki text  <==>  symbol sequence  <==>  xhtml doc
[I'm aware that there are more efficient and professional methods -- 
it's not the point here. And I like this model ;-).]
Example of a symbol type:
class Format(Symbol):
    ''' block format symbol '''
    # import relevant config data
    from_codes = config.formats.from_codes
    to_codes = config.formats.to_codes
    names = config.formats.names
    [...methods...]
Now, I want to let the user change the wiki config at runtime in order 
to 'transcode' a wiki text into another wiki language.
To achieve that, I intended to put config import instructions in a 
/type/ method, thus callable at runtime ():
class Format(Symbol):
    ''' block format symbol '''
    # import relevant config data
    def config():
        Format.from_codes = config.formats.from_codes
        Format.to_codes = config.formats.to_codes
        Format.names = config.formats.names
    [...methods...]
[...more classes...]
def config()
    config.build_config(config_file_name)
    for symbol_type in Symbol.types:
       symbol_type.config()

Problem:
I can't find any way to write a non_bound_to_an_instance method, a type 
specific method. I get of course the following:
"TypeError: unbound method config() must be called with Format instance 
as first argument (got nothing instead)"
While the Format's config() function is not intended to be a instance 
method at all. It is a type specific attribute.

Exploration:
As types (classes) are supposed to be objects, they should have their 
own attributes like any instance. Both functional (callable, methods) 
and non_functional (data, properties). Data attributes work well for a 
type, e.g.
MyType.attr = x
print MyType.attr
But strangely I can't find the way to do that for callable things:
MyType.f() launches the previous error message.
Actually, does python syntax give a way to distinguish type attributes 
from instance attributes, in the case of methods? I don't know. One can 
write:
attr            --> type property r/w (1)
MyType.attr     --> type property r/w (1)
self.attr       --> instance property r/w
???             --> type method def/call
f(self,args)    --> instance method definition
self.f(args)    --> instance method call
(1) Inside the type's definition, at upper level, the owner of the 
attribute needs not beeing specified: it is the type. Elsewhere, the 
attribute must be prefixed.
The problem may reside in the difference of syntax between properties 
and methods. To identify instance attributes, self.x is used for 
properties in both definition (write) and use (read) cases, while for 
methods the definition has to be written f(self,args) instead of 
self.f(args). Imagine that the syntax would be consistent. One could 
then write:
class T(instance):
    ''' type with type method '''
    a = 1
    def f():
        print "I'm a type method. 'a' is:", T.a
    def self.g():
       print "I'm an instance method. 'b' is:", self.b
    def self.__init__(b):
       self.b = b
T.f()
z = T(2)
z.g()
Note that this or that syntax is just a convention. And that "def 
self.g()" does not seem to conflict with present syntax rules. In fact, 
it more consistent with the rules for non-callable attributes, and 
reflects the method call syntax. At least, that's what I currently think.
Actually no syntax reflect the 'real' background process of instance 
method call, which in that case would be (note that both type and 
instance are passed as arguments):
T.__dict__['g'].__get__(z, T)
see 
[http://www.cafepy.com/article/python_attributes_and_methods/python_attributes_and_methods.html]:

Workaround:
I presently plan to 'externalise' type config functions at module level.
def format_config():
    Format.from_codes = config.formats.from_codes
    Format.to_codes = config.formats.to_codes
    Format.names = config.formats.names
[...more pseudo type-specific config functions...]
def config()
    config.build_config(config_file_name)
    format_config()
    [...more calls to type config functions...]
But I'm not happy with that at all... Type specific features should 
definitely lie inside the type's definition!

What do you think of that? Maybe an obvious python feature hasn't 
reached my mind yet...
Denis