[Python-Dev] decorator module patch (original) (raw)
Georg Brandl g.brandl at gmx.net
Sun Mar 12 15:36:57 CET 2006
- Previous message: [Python-Dev] decorator module patch
- Next message: [Python-Dev] decorator module patch
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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...
(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 'printnested'. 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
- Previous message: [Python-Dev] decorator module patch
- Next message: [Python-Dev] decorator module patch
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]