mark_bottjer at hotmail.com
Fri Aug 6 23:13:26 CEST 2004
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... :)
More information about the Python-list