Michal Kwiatkowski <[EMAIL PROTECTED]> wrote: ... > The problem wouldn't be such a problem if Python had implicit self... > but on the other side, it's another ambiguity.
In your example, you could avoid assigning var_one, but the purpose of assigning var_two and empty_list obviously would not go away with implicit self (and attendant ambiguities). > Well, maybe you can help me in refactoring this code, so that it won't > be such a pain to easily modify groups of methods? I'm thinking about this: > > def init_arguments(fun): > def new_f(self): > var_one = self.attr_one > var_two = self.attr_two.another_attr > empty_list = [] > > fun(self, var_one, var_two, empty_list) You probably want a 'return fun(...)' here, for generality. > return new_f > > @init_arguments > def method(self, var_one, var_two, empty_list): > # significant code goes here > # ... > > But the bad thing about this approach is that actual method doesn't > really look like its definition, because of different number of arguments. Yep, but to avoid black magic those names DO have to be identified as locals to the compiler at the time of the 'def method(...', which happens before the decorator gets to play. If you're keen on using those barenames as locals in method, there's no clean way out. Personally, I would give up on the bareness of the names and bunch them up into a specially named bunch, say _ (single underscore) assuming you don't need that for other purposes such as i18n. The method's signature would be a formulaic 'def method(_, self [other args if any])' -- or you could swap _ and self, if you wish; and the decorator could supply as _ a magic object (nothing black about it;-) with the suitable behavior, not just for getting attributes, but also for setting them. If you're sure you don't need to set them, then a simple Bunch instance with the usual 'class Bunch: pass', or any other such approach, will suffice. But of course, then the method's body would have to use _.one rather than var_one, _.two rather than var_two, and _.empty_list rather than empty_list (what a strange name -- does it STAY empty throughout the method's execution?!). To me this looks like a small price to pay, and the 'def method(_, self, ...)' signature a clear, strong indication that something weird, but not TOO weird, is going on. YMMV... Alex -- http://mail.python.org/mailman/listinfo/python-list
