[Python-Dev] 2.4a2, and @decorators

[Jim Fulton]

Guido van Rossum wrote:
>>In practical terms, all this means is that I'll just use the hacked
>>syntax until I no longer need to support Python 2.3.
> 
> 
> I don't understand why you prefer your hack over the established way
> to do decorators pre-2.4, which is
> 
>   def foo(): ...
>   foo = staticmethod(foo)
> 
> This works across releases (including IronPython), doesn't require any
> magic, is documented, etc.  So if your main constraint is that it be
> implementable pre-2.4, you already have a solution.  Isn't that much
> better than spending effort on hacks based on sys.settrace (which are
> surely going to produce bafflement from users who aren't familiar with
> that implementation hack)?

I think this is a great point.  It makes me wonder if:

   @staticmethod
   def foo():
       ...

if sufficiently better than:

   def foo():
       ...
   foo = staticmethod(foo)

to justify the language change. FWIW, It isn't to me.
The new syntax is yet another rule that people have to know to
understand Python code they read. That's OK if it produces enough
value to justify the burden.  I question whether that's the case here.

Perhsps the difficulty in pickling an acceptable syntax should be taken as
a warning sign that there's a problem with the feature.

I wonder if perhaps the feature is too powerful.  In particular, the need to
support passing arguments to the descriptors seemes to add a lot of syntactic
burden. I think that the most compeling common applications of decorators don't
need to have decorator expressions.

For example, for the common cases that this is trying to solve, I'd be happy
to be able to say:

   def staticmethod foo():
       ....

and allow only names as decorators.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org