@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