[Python-Dev] The decorator(s) module
Ian Bicking
ianb at colorstudy.com
Fri Feb 17 19:21:54 CET 2006
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
More information about the Python-Dev
mailing list