[Tutor] class/type methods/functions

bob gailer bgailer at gmail.com
Thu Oct 30 12:54:00 CET 2008

spir wrote:
> 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?

Take a look at the built-in functions classmethod and staticmethod
> 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
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor

Bob Gailer
Chapel Hill NC 

When we take the time to be aware of our feelings and 
needs we have more satisfying interatctions with others.

Nonviolent Communication provides tools for this awareness.

As a coach and trainer I can assist you in learning this process.

What is YOUR biggest relationship challenge?

More information about the Tutor mailing list