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