Inherit from class Decorum, instead of using @decorator

[benoitbryon]

I wonder about the usage of decorum.decorator: what about subclassing Decorum class directly?

At the moment, the documentation says:

>>> from decorum import decorator
>>> @decorator
... class fancy:
...    pass

What about replacing the example above by this one:

>>> from decorum import Decorum
>>> class fancy(Decorum):
...    pass

I think it would be easier to understand.

In fact, I don't understand the benefit (compared with direct inheritance) of this code from decorum/decorum.py:

def decorator(cls):
    class decorated(cls, Decorum):
        pass
    return decorated

[benoitbryon]

If you agree with this proposal, I will try to create a pull-request that implements the changes. Note: I'll try to remain backward-compatible, i.e. keep @decorator working.

[benoitbryon]

I think the following behaviour (decorum 0.5.1) is not easy to understand:

>>> @decorator
... class fancy:
...     pass
>>> @fancy
... def my_function():
...     pass
>>> my_function.__class__.__name__
'decorated'

I would prefer the following:

>>> class fancy(Decorum):
...     pass
>>> @fancy
... def my_function():
...     pass
>>> my_function.__class__.__name__
'fancy'

[benoitbryon]

First proposal done in #22.

I wonder about the use cases of decorum.decorator(). In the README's examples, I think subclassing decorum.Decorum is more readable and straightforward than using @decorum.decorator. And I think one way to implement the simple use case is enough. That's why I proposed this ticket and #22.

When I think about a decorator that turns Python objects into decorators, I think about contextlib. I mean:

• one can create context managers by creating a class with methods __enter__ and __exit__ => it looks like subclassing decorum.Decorum and overriding wraps() and init().
• @contextlib.contextmanager turns a function into a context manager instance => could decorum.decorator do something like that?

Such a feature could be great, but at the moment, use cases are not obvious to me. And it looks like a new feature, I mean, something different to subclassing decorum.Decorum. So, I would propose the following:

1. First focus on subclassing decorum.Decorum. Make it rock-solid and fully documented. At this stage, deprecate decorum.decorator.
2. Create another ticket about decorum.decorator, as a new feature, document specific use cases, then reintroduce implementation via a pull-request.

@zeekay: what do you think about it?

[zeekay]

I'd prefer not to deprecate usage as a decorator (if for no other reason than I find it amusing). Using contextlib could be interesting, but it's not immediately obvious to me the best way to leverage it. Some sort of transient decorator thing?