@decorators

[Mark Bottjer]

John Roth wrote:
> Since I wrote that, I managed to read the new, improved
> and rewritten PEP, and discovered that the new syntax
> doesn't allow parameters.

Sigh. My knowledge is SO last night...

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

Right. But people are still chasing after parameterized decorators, 
which is why I included the example.

Personally, I think that we will never have a "one size fits all" 
solution here, other than the one we *already* have. When doing 
something truly unusual, I see nothing wrong with using the existing 
(foo = bar(foo, baz)) syntax to do it. Syntactic sugar is about making 
common cases easier, not about providing everything for everyone.

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

Agreed. Along the same lines, I read a post elsewhere which reminded us 
that we can always *relax* the restrictions later, once we understand 
what we actually want. Sage advise.

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

I try not to... :)

   -- Mark