On Jun 28, 2004, at 12:48 PM, Barry Warsaw wrote: > On Mon, 2004-06-28 at 13:27, Jeff Bone wrote: >> Okay, this is a great and meaty example, thanks Barry. It's the first >> one that I've seen that is clearly not a purely declarative thing at >> least in the abstract. What would the proposed decorator version of >> this look like? > > Depends on which syntax Guido chooses <wink>. C'mon, Barry, work with me here. ;-) I'm not as interested in the specific syntax as what the syntax implies about the semantics. > I'd be able to remove all the "func = txnprop(_func)" trailers, and do > something like: > > [txnprop] > def create_list(self, listid): > # ... > > All of which seem much more clear than what I currently have to do. Granted. But let's look at the above. Now, you're intimately familiar with the current implementation of txnprop, so you think of the above in terms of its literal side-effecting behavior. But looking at it as a consumer of the interface --- simply as a user reading the code, or as some automated tool which doesn't understand and doesn't necessarily NEED to understand the effect of txnprop, that looks awfully declarative --- doesn't it? You're in essence saying "the following is a transactional function." So on closer examination it looks like this application can still be given purely declarative semantics from the API consumer's perspective. That's not going to screw up e.g. typing --- particularly not if e.g. the implementation of txnprop is further decorated to indicate what exceptions are thrown, etc. It doesn't so much *modify* the behavior of create_list from the API consumer's (human or otherwise) perspective as it does *declare* what it is. jb
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