@decorators

[John Roth]

"Mark Bottjer" <mark_bottjer at hotmail.com> wrote in message
news:4113e5be at nntp.zianet.com...
> 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.

Since I wrote that, I managed to read the new, improved
and rewritten PEP, and discovered that the new syntax
doesn't allow parameters. So it can't be used as a replacement
for the property() built-in function, and it therefore also can't
be used for the DBC functionality. As delivered, it's strictly
a replacement for the classmethod and staticmethod
builtin functions (and any other module or builtins that
take one parameter, of course.)

Guido's stated reasoning was that he had "a bad feeling"
about allowing more general expressions. So do I.
>From what people are saying that's substantive (rather
than syntactic) I think that there are a number of very
different desires on the table, and it's not at all clear
either what they are or how they combine.

> 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. :)

He's been through it before. Remember PEP 308?

John Roth
>
>    -- Mark