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