At 09:22 PM 7/15/04 -0400, Raymond Hettinger wrote: >The reason is the feature request is currently out of favor is the >possibility that the syntax would be abused and people would start >defining their methods outside of class definitions. That sounds like a feature to me. :) I've just finished drafting an extensible generic function framework using decorators, like this stupid trivial non-motivating example: [when("x<2")] def fact(x): return 1 [when("True")] def fact(x): return x * fact(x-1) Generic functions are a great way to structure an extensible framework, where the base function is defined in one module, and then other modules add cases to the function, like: from storage_framework import save_ob [when("ob in Invoice and db in Oracle")] def save_ob(db, ob): # code to write Invoice to Oracle So, with your syntax, you could instead do: import storage_framework [when("ob in Invoice and db in Oracle")] def storage_framework.save_ob(db, ob): # code to write Invoice to Oracle which is much clearer as to intent, although I must confess I have no clue how I'd make it work with my current decorator implemenation, which looks for changes in the frame's locals. As for declaring methods outside a class, this is actually a good idea for certain generic functions. Say for example that 'save_ob' was actually a method of the database type, rather than being a "free range" generic function. Then, the above would be written as: [when("ob in Invoice")] def Oracle.save_ob(self, ob): # code to write Invoice to Oracle which is even clearer as to intention. But, I think that there'd have to be integrated decorator support for it to be really useful, at least for me.
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