[Python-Dev] block-based decorators and other block issues
bob at redivi.com
Sun Aug 15 22:59:35 CEST 2004
On Aug 13, 2004, at 8:20 AM, Martin Zarate wrote:
> Our discussion has taken an interesting turn, leading to this concept
> of "super-decorators" that are more versatile than normal decorators,
> they can accept multiple objects, and because they can play with
> The reason is simple - speed. A decorator shouldn't have to perform
> fasttolocals and vice versa. It doesn't need to be its own variable
> namespace - it can sit within the external namespace. To do otherwise
> suboptimal. The decorator should not have its own scope. Instead, it
> provide a simple filter.
Ok, I agree with you throughout this post except for this "speed"
business. Decorators are largely considered a compile-time feature and
will almost exclusively be executed as module-level code. Each
'decorator statement' will likely only be executed once in its entire
lifetime upon module import. I don't think speed is too much of a
concern at this point and worrying about it definitely seems like one
heck of a premature optimization.
More information about the Python-Dev