Closed benoitbryon closed 9 years ago
I agree.
Oooops, I started working on such a refactor, and I'm not sure it is a good idea... What happens if, as a user, I want to change the wrapped function?
In current 1.0.0 version:
class my_decorator(Decorum):
def wraps(self, f):
new_function = lambda: True
return super(my_decorator, self).wraps(new_function)
Calling super()
makes sense. And we don't have to bother with Decorum's internal self._wrapped
actually :)
If we move self._wrapped
assignment in __init__()
and __call__()
, the example above will change like this:
class my_decorator(Decorum):
def wraps(self, f):
new_function = lambda: True
self._wrapped = new_function
return super(my_decorator, self).wraps(self._wrapped) # Optional, but still recommended.
Here, we do have to know and care about self._wrapped
, which is exactly what I wanted to avoid :(
Yeah that makes sense.
I propose closing this issue as wontfix. And if we have a better idea later, let's reopen or create a new ticket ;)
By the way, thank you @zeekay for being so responsive!
Haha, no worries, I'm always in a terminal ;)
As of Decorum version 1.0.0, special attribute
Decorum._wrapped
is assigned withinwraps()
. See https://github.com/zeekay/decorum/blob/1.0.0/decorum/decorum.py#L57It works quite well. But it means users MUST call
super().wraps()
if they overridewraps()
method, else the_wrapped
attribute would be broken.I wonder if we could move the setup of
self._wrapped
within both__init__()
and__call__()
, so that users who don't callsuper().wraps()
just miss theassigned
feature.In general, I like the idea that Decorum's "magic" lives within
__init__()
and__call__()
, whereas methods such asinit()
,wraps()
andcall()
are simple to understand and override. Then I thinkself._wrapped
is part of Decorum's magic, i.e. users should not have to bother about it in most cases.