Decorator syntax
Mark 'Kamikaze' Hughes
kamikaze at kuoi.asui.uidaho.edu
Thu Aug 5 16:31:00 EDT 2004
C. Barnes <connellybarnes at yahoo.com>
wrote on Wed, 4 Aug 2004 18:42:48 -0700 (PDT):
> I vote for
> def f(): [synchronized, classmethod]
> (body of function)
That syntax looks plausible in toy examples, but is terrible for a
more typical invocation, like:
class foo:
def introduceNewFeature(self, someArgument, anotherArgument): [synchronized, types="o,i,i"]
pass # whatever
> This is backwards compatible (Python <= 2.3 raise
> SyntaxError),
That's not what "backwards compatible" means, but @-syntax also raises
a syntax error in older versions, which is just what you'd expect.
> and looks much nicer than @.
I fail to see how that's more attractive than:
class foo:
@synchronized
@types("o,i,i")
def introduceNewFeature(self, someArgument, anotherArgument):
pass # whatever
I'm +1 for the @-syntax.
1) It doesn't cause needless line-wrap.
2) It causes the minimum amount of confusion, because it doesn't
overload an existing symbol. [] and {} and () are already pushed to
their limits and beyond in Python. Give them a day off for once.
3) A large proportion of Python programmers are also Java programmers,
and won't object to the @-syntax.
> The only problem is that you can't one-line a
> decorated function. You can't do that with
> the @ notation either, so it's not a big deal.
One-liners are of negative value to a language, anyway, as they
encourage bad habits. That way lies Perl and other juvenile
entertainments.
--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"Virtues foster one another; so too, vices.
Bad English kills trees, consumes energy, and befouls the Earth.
Good English renews it." -The Underground Grammarian, v1n2
More information about the Python-list
mailing list