[Python-Dev] decorator module patch
Nick Coghlan
ncoghlan at gmail.com
Sun Mar 12 15:10:58 CET 2006
Georg Brandl wrote:
> Hi,
>
> to underlay my proposals with facts, I've written a simple decorator
> module containing at the moment only the "decorator" decorator.
>
> http://python.org/sf/1448297
>
> It is implemented as a C extension module _decorator which contains the
> decorator object (modelled after the functional.partial object) and a
> Lib/decorator.py to allow further decorators added as Python code.
>
> Comes with docs and unit test.
Given that @decorator is a definition time only operation to modify a
function's __name__, __doc__ and __dict__ attributes, and doesn't actually
introduce any extra levels of run-time nesting to function calls, I'm not
clear on why you bothered with a hybrid implementation instead of sticking
with pure Python.
(To clarify what I mean: using the example in the doc patch, the extra layer
of run-time nesting from @decorator's wrapper function applies only to the
@logged decorator, not to the function 'print_nested'. If an application has a
decorated function definition in a performance critical path, a little bit of
extra overhead from @decorator is the least of its worries.)
Also, I thought we were trying to move away from modules that shared a name
with one of their public functions or classes. As it is, I'm not even sure
that a name like "decorator" gives the right emphasis.
In general, decorators belong in the appropriate domain-specific module
(similar to context managers). In this case, though, the domain is the
manipulation of Python functions - maybe the module should be called
"metafunctions" or "functools" to reflect its application domain, rather than
the coincidental fact that its first member happens to be a decorator.
Regards,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
More information about the Python-Dev
mailing list