[Python-Dev] Re: decorators and 2.4

[Jeff Bone]

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