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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4