[Python-Dev] block-based decorators and other block issues

Bob Ippolito 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, 
> because
> they can accept multiple objects, and because they can play with 
> namespaces.
---
> 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 
> is
> suboptimal.  The decorator should not have its own scope.  Instead, it 
> should
> 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.

-bob


More information about the Python-Dev mailing list