Paolino wrote: > I noticed (via using them) that decorations are applied to methods > before they become methods. > > This choice flattens down the implementation to no differentiating > methods from functions. > > > > 1) > I have to apply euristics on the wrapped function type when I use the > function as an index key. > > if type(observed) is types.MethodType: > observed=observed.im_func > > things like this are inside my decorators. > > 2) > The behavior of decorations are not definable. > I imagine that a method implementation of them inside the type metaclass > could be better specified by people. > This probably ends up in metamethods or something I can't grasp > A downside of decorating at function level is that it's virtually impossible to check from the decorator that the first call parameter (aka self) is an instance of the method class.This check must be done inside the decorated. This can really happen in normal use as decorators are useful to register the decorated as a 'callback'.Who ever fires it can do it with no respect on the class belonging of the function/method, and the error raised will not be coherent with 'calling method on a incompatible instance'.
Maybe it's possible to let the decorator know the method class even if the class is still undefined.(Just like recursive functions?) This would allow decorators to call super with the right class also. @callSuper decoration is something I really miss. Thanks Paolino _______________________________________________ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com