[Python-Dev] The decorator(s) module

[Ian Bicking]

Georg Brandl wrote:
> Hi,
> 
> it has been proposed before, but there was no conclusive answer last time:
> is there any chance for 2.5 to include commonly used decorators in a module?

One peculiar aspect is that decorators are a programming technique, not 
a particular kind of functionality.  So the module seems kind of funny 
as a result.

> Of course not everything that jumps around should go in, only pretty basic
> stuff that can be widely used.
> 
> Candidates are:
>  - @decorator. This properly wraps up a decorator function to change the
>    signature of the new function according to the decorated one's.

Yes, I like this, and it is purely related to "decorators" not anything 
else.  Without this, decorators really hurt introspectability.

>  - @contextmanager, see PEP 343.

This is abstract enough that it doesn't belong anywhere in particular.

>  - @synchronized/@locked/whatever, for thread safety.

Seems better in the threading module.  Plus contexts and with make it 
much less important as a decorator.

>  - @memoize

Also abstract, so I suppose it would make sense.

>  - Others from wiki:PythonDecoratorLibrary and Michele Simionato's decorator
>    module at <http://www.phyast.pitt.edu/~micheles/python/documentation.html>.

redirecting_stdout is better implemented using contexts/with.  @threaded 
(which runs the decorated function in a thread) seems strange to me. 
@blocking seems like it is going into async directions that don't really 
fit in with "decorators" (as a general concept).

I like @tracing, though it doesn't seem like it is really implemented 
there, it's just an example?

> Unfortunately, a @property decorator is impossible...

It already works!  But only if you want a read-only property.  Which is 
actually about 50%+ of the properties I create.  So the status quo is 
not really that bad.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org