Re: Better @g.command decorator

2015-05-18 Thread Edward K. Ream
On Mon, May 18, 2015 at 3:45 AM, reinhard.engel...@googlemail.com wrote: ​ ​ Maybe you should using different decorators. ​I think the present code is good enough. Certainly @keybinding isn't needed. The defaults ​ ​belong in leoSettings.leo. Imo, the @g.cmd project has completed

Re: Better @g.command decorator

2015-05-18 Thread reinhard . engel . de
Maybe you should using different decorators. No, it doesn't work. In ​leo/commands/helpCommands I replaced:​ def cmd(name): '''Command decorator for the helpCommands class.''' return g.new_cmd_decorator(name,['c','helpCommands',]) with cmd = g.cmd where g.cmd is defined as you

Re: Better @g.command decorator

2015-05-17 Thread reinhard . engel . de
Forget the decorator! I'm not sure what you try to accomplish. Your publicCommands tables in Leo already associate command_names with functions or methods, so you don't need a decorator for that. As you told Terry (somewhere above) you need to retrieve the information if you need a 'self'

Re: Better @g.command decorator

2015-05-17 Thread Edward K. Ream
​​ ​​On Sun, May 17, 2015 at 4:04 AM, reinhard.engel...@googlemail.com wrote: ​ ​ Forget the decorator! ​:-)​ The per-class (per-module) decorators in Leo's code do work, they are defined before the class to which they apply and the decorators themselves appear before what *looks *to be a

Re: Better @g.command decorator

2015-05-16 Thread reinhard . engel . de
There is no need to 'compute' the class, because the class is stored in the decorator, wenn the command is created. I post my code from the other thread here again. When Leo sees a command, it looks up the wrapper in the dict and simply calls the wrapper with an event arg. The *wrapper

Re: Better @g.command decorator

2015-05-16 Thread Edward K. Ream
On Thursday, May 14, 2015 at 11:09:47 AM UTC-5, Edward K. Ream wrote: ​Not sure why it works, but I see that it does... this decorator should replace g.command and all other cmd decorators. Upon further review, I don't believe this problem is solvable. This snippet: type0 = args and

Re: Better @g.command decorator

2015-05-16 Thread Edward K. Ream
On Sat, May 16, 2015 at 4:59 PM, reinhard.engel...@googlemail.com wrote: There is no need to 'compute' the class, because the class is stored in the decorator, w ​hen​ the command is created. I post my code from the other thread here again. ​Yes, I think you have solved all the problems,

Re: Better @g.command decorator

2015-05-16 Thread Edward K. Ream
On Saturday, May 16, 2015 at 6:26:17 PM UTC-5, Edward K. Ream wrote: I think you have solved all the problems... No, it doesn't work. In ​leo/commands/helpCommands I replaced:​ def cmd(name): '''Command decorator for the helpCommands class.''' return

Re: Better @g.command decorator

2015-05-14 Thread Edward K. Ream
On Thu, May 14, 2015 at 5:04 AM, reinhard.engel...@googlemail.com wrote: So it looks like we're stuck. Any ideas? Apart from using a sophisticated decorator you could just pass the class name as an optional parameter in @cmd(command_name, class_name=None) I'm no expert here, but this

Re: Better @g.command decorator

2015-05-14 Thread Edward K. Ream
On Thu, May 14, 2015 at 4:44 AM, reinhard.engel...@googlemail.com wrote: ​ ​ So it looks like we're stuck. Any ideas? ​ ​ This works for both Python2 and Python3: ​Excellent! Not sure why it works, but I see that it does :-) I'm in the midst of a big code reorg at present. When that is done,

Re: Better @g.command decorator

2015-05-14 Thread reinhard . engel . de
So it looks like we're stuck. Any ideas? This works for both Python2 and Python3: from functools import wraps isPython3 = True def cmd(command_name): def inner_cmd(func): @wraps(func) def _decorator(*args, **kwargs): type0 = args and str(type(args[0])) or

Re: Better @g.command decorator

2015-05-14 Thread reinhard . engel . de
So it looks like we're stuck. Any ideas? Apart from using a sophisticated decorator you could just pass the class name as an optional parameter in @cmd(command_name, class_name=None) I'm no expert here, but this would require about 150 changes in the Leo code base and could be done by a

Re: Better @g.command decorator

2015-05-13 Thread reinhard . engel . de
It's even easier: You don't need a class decorator but can retrieve the class nam from th decorator's __dict__: commands_dict = {} ivars_dict = {} # Use as function/method decorator def cmd(command_name): class Decorator: def __init__(self, func): self.func = func

Re: Better @g.command decorator

2015-05-13 Thread reinhard . engel . de
Instead of using per plass decorators you might use a class decorator that enhances the function/method decorators with the class name: commands_dict = {} ivars_dict = {} # Use as function/method decorator def cmd(command_name): class Decorator: def __init__(self, func):

Re: Better @g.command decorator

2015-05-13 Thread Edward K. Ream
On Wednesday, May 13, 2015 at 5:13:46 AM UTC-5, reinhard.engel...@googlemail.com wrote: It's even easier... There is no obvious way to recover the class name in Python 2. Here is my test code: def cmd(command_name): def _decorator(func): base = func.__code__ if g.isPython3

Re: Better @g.command decorator

2015-05-13 Thread Edward K. Ream
On Wed, May 13, 2015 at 5:13 AM, reinhard.engel...@googlemail.com wrote: ​ ​ It's even easier: You don't need a class decorator but can retrieve the class ​name from the ​decorator's __dict__. Many thanks for your continued work. Given the class name, the decorator could get the instance from

Re: Better @g.command decorator

2015-05-11 Thread Edward K. Ream
On Monday, May 11, 2015 at 6:51:38 AM UTC-5, john lunzer wrote: Out of curiosity, how do you ensure singleton-ness of the LeoApp class? I didn't see anything special precautions in the class definition. There is nothing special about the LeoApp class. It simply gets instantiated once. Some

Re: Better @g.command decorator

2015-05-11 Thread john lunzer
Out of curiousity, how do you ensure singleton-ness of the LeoApp class? I didn't see anything special precautions in the class definition. On Sunday, May 10, 2015 at 1:10:43 PM UTC-4, Edward K. Ream wrote: On Sunday, May 10, 2015 at 11:51:23 AM UTC-5, Edward K. Ream wrote: *

Re: Better @g.command decorator

2015-05-11 Thread Edward K. Ream
On Sunday, May 10, 2015 at 7:03:02 AM UTC-5, Edward K. Ream wrote: The primary task is to associate a decorator with an *instance *of a class. The code that I pushed yesterday does this by defining a cmd decorator for each class that defines a Leo command. When I awoke this morning I saw

Re: Better @g.command decorator

2015-05-11 Thread 'Terry Brown' via leo-editor
| On Mon, 11 May 2015 05:16:24 -0700 (PDT) | Edward K. Ream edream...@gmail.com wrote: :: On Sunday, May 10, 2015 at 7:03:02 AM UTC-5, Edward K. Ream wrote: The primary task is to associate a decorator with an *instance *of a class. The code that I pushed yesterday does this by defining

Re: Better @g.command decorator

2015-05-10 Thread Edward K. Ream
​​ ​On Sat, May 9, 2015 at 11:58 PM, reinhard.engel...@googlemail.com wrote: The main point is to tell a function from a method. If you don't want to use __qualname__ one might use the inspect module. But assuming the Python convention to name the first argument of method 'self', the foll

Re: Better @g.command decorator

2015-05-10 Thread Edward K. Ream
On Sunday, May 10, 2015 at 7:03:02 AM UTC-5, Edward K. Ream wrote: single dict, say *g.cmd_instance_dict*, could eliminate the need for per-class decorators. This dict is Leo's Rosetta Stone! Here it is: cmd_instance_dict = { # Keys are class names, values are attribute chains. #

Re: Better @g.command decorator

2015-05-10 Thread Edward K. Ream
On Sunday, May 10, 2015 at 11:51:23 AM UTC-5, Edward K. Ream wrote: * *g.cmd_instance_dict..is Leo's Rosetta Stone! The implications keep getting more interesting. 1. This dict is independent of packaging! The classes mentioned in the dict may be defined in any module. 2. Classes containing

Re: Better @g.command decorator

2015-05-09 Thread reinhard . engel . de
​ This works without static/class methods and is a little less involved: ​A nice idea, but __qualname__ is Python 3 only. The main point is to tell a function from a method. If you don't want to use __qualname__ one might use the inspect module. But assuming the Python convention to name

Re: Better @g.command decorator

2015-05-09 Thread reinhard . engel . de
I would *much *rather do this than use class methods anywhere in Leo. YMMV, but you have little chance of changing my mind. Yes, there is a bit more code involved, but it is completely encapsulated. In contrast, static/class methods have global consequences. I'm not going there.

Re: Better @g.command decorator

2015-05-08 Thread reinhard . engel . de
*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] =

Re: Better @g.command decorator

2015-05-08 Thread Edward K. Ream
On Tuesday, May 5, 2015 at 10:20:20 AM UTC-5, Edward K. Ream wrote: [The new @cmd] decorator would eliminate the need for command-definition tables that occur in various places in leoEditCommands.py and leoCommands.py. Rev 1789ef6 contains @button create decorators in scripts.leo that will

Re: Better @g.command decorator

2015-05-08 Thread reinhard . engel . de
In the 5th edition of 'Learning Python', pages 1289ff, Mark Lutz discusses extensively solutions for decorators that work on *both *simple functions and class-level methods (with passing instances!). Reinhard -- You received this message because you are subscribed to the Google Groups

Re: Better @g.command decorator

2015-05-08 Thread Edward K. Ream
​​ On Fri, May 8, 2015 at 2:45 PM, reinhard.engel...@googlemail.com wrote: ​ ​ Why do you need instance methods (using 'self') ​...you ​could use static class methods; and with these *one *decorator works perfectly well: That would work. But I won't do it. I have never seen a class methods that

Re: Better @g.command decorator

2015-05-07 Thread Edward K. Ream
On Wednesday, May 6, 2015 at 10:55:31 AM UTC-5, Edward K. Ream wrote: The goal is simple: improve the g.command decorator so that all commands can be defined like this: @g.command('command-name') def do_command(self,event=None): '''Implement the command''' This is turning

Re: Better @g.command decorator

2015-05-06 Thread Edward K. Ream
On Tuesday, May 5, 2015 at 10:20:20 AM UTC-5, Edward K. Ream wrote: The goal is simple: improve the g.command decorator so that all commands can be defined like this: @g.command('command-name') def do_command(self,event=None): '''Implement the command''' This is an interesting

Re: Better @g.command decorator

2015-05-05 Thread Edward K. Ream
On Tuesday, May 5, 2015 at 10:20:20 AM UTC-5, Edward K. Ream wrote: The goal is simple: improve the g.command decorator so that all commands can be defined [using it] I'll define @g.cmd for development. When everything works I'll change @g.cmd to @g.command. Much safer than messing with