I would code it as two different methods just like in standard method factory pattern description. https://www.oodesign.com/factory-method-pattern.html class Foo(object): __metaclass__ = abc.ABCMeta @abc.abstractmethod @some_decorator def my_method(self, x): self.child_method() class SubFoo(Foo): def child_method(self, x): print x
A do-nothing decorator class would look like this: class NullDecl (object): def __init__ (self, func): self.func = func for name in set(dir(func)) – set(dir(self)): setattr(self, name, getattr(func, name)) def __call__ (self, *args): return self.func (*args) And then you can apply it normally: @NullDecl def myFunc (x,y,z): return (x+y)/z
Another approach, thanks to a suggestion from @DarkSquirrel42, is to use an InjectionFactory. The downside is that the code still needs updating every time a new constructor parameter is added to something in the chain. The advantages are much easier to understand code, and only a single registration into the container. Func<IUnityContainer,object> createChain = container … Read more
Better one and a half year late than never: A base class for decorators of a certain interface is not necessary. However, it is very useful to have: for one thing, as a means of documenting that classes derived from it are decorators of the interface in question but mostly, because decorators usually do not … Read more
I’m surprised that this question is so old and no one has taken the time to add the actual introspective way to do this, so here it is: The code you want to inspect… def template(func): def wrapper(*args, **kwargs): return func(*args, **kwargs) return wrapper baz = template che = template class Foo(object): @baz @che def … Read more
I would use a retry decorator. There are other ones out there, but this one works pretty well. Here’s how you can use it: @retry(urllib2.URLError, tries=4, delay=3, backoff=2) def urlopen_with_retry(): return urllib2.urlopen(“http://example.com”) This will retry the function if URLError is raised. Check the link above for documentation on the parameters, but basically it will retry … Read more
the __exit__() method should accept information about exceptions that come up in the with: block. See here. The following modification of your code works: def __exit__(self, exc_type, exc_value, tb): if exc_type is not None: traceback.print_exception(exc_type, exc_value, tb) # return False # uncomment to pass exception through return True Then you can try raising an exception … Read more
It seems py.test doesn’t use the test fixtures when evaluating the expression for skipif. By your example, test_ios is actually successful because it is comparing the function platform found in the module’s namespace to the “ios” string, which evaluates to False hence the test is executed and succeeds. If pytest was inserting the fixture for … Read more
std::function provides most of the building blocks for my proposed solution. Here is my proposed solution. #include <iostream> #include <functional> //——————————- // BEGIN decorator implementation //——————————- template <class> struct Decorator; template <class R, class… Args> struct Decorator<R(Args …)> { Decorator(std::function<R(Args …)> f) : f_(f) {} R operator()(Args … args) { std::cout << “Calling the decorated … Read more
Decorators usually return a wrapper function; just put your logic in the wrapper function after invoking the wrapped function. def audit_action(action): def decorator_func(func): def wrapper_func(*args, **kwargs): # Invoke the wrapped function first retval = func(*args, **kwargs) # Now do something here with retval and/or action print(‘In wrapper_func, handling action {!r} after wrapped function returned {!r}’.format(action, … Read more