[Python-Dev] The decorator(s) module (original) (raw)

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