On Dec 31 2007, 6:03 pm, Scott David Daniels <[EMAIL PROTECTED]> wrote: > As to the original idea, better to give it up. > Typically code for a "chained" method "foo" that > returns a result will want to (in some way) use > the result from that call in forming its result. > Python's super allows you to place that call where > it belongs in your code (perhaps after some logging > is enabled, for example) and not just "at the spot > the guru insists the chaining happens."
Indeed I might want to chain methods in all sort of ways: @chain_call_before - call the parent's method before the derived method @chain_call_after - call the parent's method after the derived method @chain_call_sum - sum the result of the parent's method with the result of the derived method @chain_call_list - make a list from the result of the parent's method and the result of the derived method An API for easily adding chaining methods is also something to think about. This kind of chaining actually exists in Common Lisp (CLOS) and I wish for something like that in Python so I gave it a(n unsuccessful) try. I think that especially Python, which is known (among other things) for its object oriented properties, should support this kind of chaining. >simply remind people to call > A.foo(self, <args>) within the definition of foo in > B. Sorry, I can't agree to this (although there is nothing else I can do.. :-) . Reminding is not "simply" at all. Why REMIND people do stuff and not let Python handle it automatically? What's Python (and all other powerful languages) for if not for this kind of job? (Although I think this "chaining" is not supperted by none of them except for Lisp). Although I actually work in a C++ team, and all the Python I do is for myself so I don't have to remind anyone, I think this mechansim is necessary. What actually made me intereseted in that is a C++ application I write where I figured that chaining would help. If I translate it to Python, it's something like this: (I'm still not familiar with new style classes so please forgive me..) class Inetrface_system: def get_name(self): return "No_name" get_name is an interface function which the programmer calls in the application. This is a new system: class System_A(Interface_system): def get_name(self): return "System_A" There are several dereived classes like System_A. I need to log each call to get_name for any class, but I just can't rely on remembering (by progammers) to add this extra themselves for get_name for each class they derive: class Inetrface_system: def get_name(self): log_to_file('get_name called') return "No_name" class System_A(Interface_system): def get_name(self): Interface_system.get_name() # can be forgotten return "System_A" One solution is: class Interface_system(): def get_name_api(self): log_to_file('get name called') return get_name() def get_name(self): return 'No name' class System_A(Interface_system): def get_name(self): return 'System_A' So programmers need only override get_name. But this makes it confusing: One has to override get_name, but must call get_name_api throughout the application. I don't like it. So, recalling CLOS I thought of a better way: class Inetrface_system: @cained_call_before def get_name(self): log_to_file('get_name called') @chained class System_A(Interface_system): def get_name(self): return 'System_A' Now the programmer both overrides get_name, and calls get_name directly in the application. And no one has to remember to call the parent's get_name method. It's done automatically. (A PEP maybe? I sense you don't really like it.. ;-) What do you think? Good? Too implicit? iu2 -- http://mail.python.org/mailman/listinfo/python-list