@decorators

Mark Bottjer mark_bottjer at hotmail.com
Fri Aug 6 16:10:37 EDT 2004


John Roth wrote:
> All of the existing packages (at least to my knowledge) use
> descriptors to wrap the necessary functions. They could be
> very easily reimplemented in terms of the decorator syntax.
> However, the decorator syntax brings no new functionality
> to the table; it's simply syntactic sugar for already existing
> functionality.

Exactly. What's more, I don't think that decorators are really the ideal 
way to express DBC, either. For one thing, pre and post conditions often 
want access to at least the argument list, and often to the internal 
variables of the definition. I don't think that this will be possible 
with the decorators as proposed, since they are outside the scope of the 
function.

> It may, of course, improve readability, which is always
> desirable.

I think readability would be improved more by adding support in the form 
of special control blocks (more like if and while than def or class):

class C:
   def f( self, a, b):
     pre:
       assert type(a) == types.int
       assert type(b) == types.int
       assert a < b
     post:
       assert (rc is None) or (type( rc) == types.list)
     if (a % b) > (a / b):
       return None
     return (a % b) * (a / b)

Bringing this back on topic, the decorator syntax could theoretically be 
extended to support this:

class C:
   def f( self, a, b):
     @pre:
       ...
     @post:
       ...
     if ...

That is, decorators optionally could accept a block of code along with 
their explicit arguments. What they do with that block is up to them. Of 
course, I'm not familiar enough with the internals to know how feasible 
this would be...

> "Roy Smith" <roy at panix.com> wrote...
>>Lastly, and perhaps most importantly, I'm rather distressed at the tone
>>of some of the postings I've seen here over the past couple of days.
>>Some of the sentiments I've seen expressed are downright rude,
>>combative, and accusatory.  These sorts of things are way out of line.

Agreed. I think we're all a bit on edge at seeing something we think 
might still be flawed about to be canonized, but bickering won't help 
anything.

Don't forget: if we make this too painful for the BDFL, he might just 
drop the whole idea and tell us to live with what we've got. :)

   -- Mark



More information about the Python-list mailing list