*A two-level solution*
>
> Rather than using a single command-decorator, we must use separate 
> decorators for each defining class:
>
> commands_dict = {}
>
> class TestClass:
>     def cmd(name):
>         def _decorator(func):
>             commands_dict[name]= func
>             ivars_dict[name] = 'testClass'
>                 # c.testClass is a singleton instance of TestClass.
>             return func
>         return _decorator
>
>     @cmd('command1')
>     def method1(self,event=None):
>         '''method1 docstring.'''
>         return self.__class__.__name__
>
> The idea is that the dispatch code will look something like this:
>
> func = commands_dict.get(command_name)
> ivar = ivars_dict.get(command_name)
> obj = getattr(c,ivar) if ivar else c
> func(obj,event)
>
>
> It should now be pretty clear that there is no possible way for any 
> decorator to know about c.testClass automatically.  This knowledge must be 
> built in to each decorator.
>

What I don't understand: Why do you need instance methods (using 'self') if 
you are working with a singleton,
because in this case:  c.testClass == TestClass? Then you colud use static 
class methods; and with these *one *decorator works perfectly well:

commands_dict = {}
ivars_dict = {}

def cmd(name):
    def _decorator(func):
        commands_dict[name] = func
        ivars_dict[name] = 'testClass'
            # c.testClass is a singleton instance of TestClass.
        return func
    return _decorator

@cmd('command1')
def pureFunction(event=None):
    """pureFunction docstring"""
    print("pureFunction")


class MyClass:

    @cmd('command2')
    def staticClassMethod(event=None):   # No 'self' here!
        """staticClassMethod docstring"""
        print("staticClassMethod")

f1 = commands_dict['command1']
f1()
print(ivars_dict['command1'])

f2 = commands_dict['command2']
f2()

print(ivars_dict['command2'])

This gives the output:

pureFunction
testClass
staticClassMethod
testClass


Of course, this doesn't work with instances of classes. But without looking 
at the Leo code, do you really want to bind Leo commands to instances of 
classes?

Reinhard
 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to