[Tutor] class/type methods/functions

[bob gailer]

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 
919-636-4239

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?