[Python-ideas] type/instance method syntax

[spir]

Hello,

[New to the list. I spent some time exploring the archives, still I'm 
not really sure of what kind of subjects fit here -- or not. If ever 
this post, or a further one, is out of topic, just tell me.
Also, I'm a self-trained amateur, and neither python nore english is my 
native language, thus I may use non-standard idioms. ;-)]

-1- real-life case (can safely be skipped)

I'm writing an application that should allow a user to chose between 
several wiki languages, including customized versions, on one side; and 
uses either a subset of xhtml, or simple plain text tables (simulation 
of DB import/export), as saving/exchange/standard format.
To do this, I have a whole lot of configurable "Symbol" sub-types, each 
representing a common language feature. (I imagine there are tons of 
more professional approaches, but this is not my point -- I do it for 
pleasure.) A list of symbols (instances), parsed from a source text, 
build an abstract, language-independant, image of the text. The types 
have to take the (wiki-side) configuration into account; I also wish 
this config to be "switchable" at run-time. An example use of this 
feature is to "transcode" a wiki source text into another wiki format.
The pattern of a symbol type is then:

class BlockFormat(Symbol):
    def config():
        <set type attributes>
    def __init__(self, source, ...):
        <read instance attributes from source doc>
    <read/write methods from/into known languages>

I /really/ expected this to work. config() obviously was, for me, a 
type/class method. I intended to call it and its sisters from a module 
top-level function:
def config():
    wiki_config.build(config_file_name)
    for symbol_type in symbol_types:
        symbol_type.config()

As a consequence, I happily discovered both classmethod() and 
@classmethod.(Actually, I hadn't programmed for a long time, had 
forgotten some idiomatic "details", and knew about nothing of python >= 
2.0, except for the overall new_style_classes pattern.)

-2- type/instance attribute pattern

(Below is called 'property' a non-callable object attribute, as opposed 
to 'method'. I do not know if a better, standard, term is used in the 
python community.)

                type/class          instance
property        prop                self.prop
method call     f(args)             self.f(args)
method def      def f(args)+X       def f(self,args)

(where X means either classmethod() or @classmethod)

I wondered where the point is before writing down this table. Why (1) I 
intended my code to work as is (2) we need to add a line of code to 
define a class method.
In order to distinguish an instance property from a type one, the former 
is simply prefixed with 'self' -- or any placeholder for a potential 
instance name --, later with the actual instance's name. This pattern 
fully applies to method call. But is broken for method definition, for 
any reason I'm unable to guess. I think this explains why I wrote the 
code above.
Now, watching such a table, the additional instruction looks to my eyes 
like a workaround rather than a feature. Actually, the instance method 
definition syntax takes the place of
the one that may be expected for class methods instead. Lets imagine 
this slight change:

                type/class          instance
property        prop                self.prop
method call     f(args)             self.f(args)
method def      def f(args)         def self.f(args)       <==

Doesn't this deliciously fit in the table? Not only the syntax for 
instance method definition matches the call syntax; but also the whole 
method pattern matches the one for properties.

-3- proposal

I am fully conscious that this syntax cannot be introduced: this would 
have as magic side-effect to transform all instance methods into class 
methods ;-)

I wonder if the following may be considered: Allow prefixing of class 
attributes (esp. methods) with the classe's name -- even in the classe's 
own scope:
class C(object):
    C.a = 1
    def C.f():
        <method body>
This syntax presently launches NameError and SyntaxError, which is 
correct as C is not yet defined, and the second syntax is unknown. 
But... it would allow a nicer syntax to define class method, and more: 
this syntax is precisely the one that will later be used to call the method.

An alternative may be to prefix a class method defintition with either 
'type' or 'class', used as a pseudo keyword:
class C(object):
    def type.f():
        <method body>

Denis