[Python-Dev] decorator module patch

[Georg Brandl]

Nick Coghlan wrote:
> 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.

Good question... partly because I wanted to make myself more intimate with the
C API and extension modules. Everyone can write that in Python... <wink>

> (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.)

Right. I'm not opposed to a Python-only module, I've had my fun :)

> 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.

I thought about "decorators" too, that would make "decorators.decorator". Hm.

> 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.

Depends on what else will end up there. If it's "memoize" or "deprecated" then
the name "functools" doesn't sound too good either.

Georg