[Python-Dev] Re: PEP 318: Decorators last before colon

[Holger Krekel]

Hi Bob, 

Bob Ippolito wrote:
> On Mar 31, 2004, at 1:59 PM, Michel Pelletier wrote:
> >Please don't add any decorator syntax to Python, at least not yet.  All
> >of the proposals I have seen so far are, to be blunt, and in my opinion
> >of course, ugly and are getting uglier as the discussion ensues.
> >
> >I see nothing wrong, at least for the present, with the status quo
> >decorators that follow a function or class definition.  They are
> >explicit, functionally equivalent, use the existing and completely
> >understandable syntax, and are so rarely used by only the *most*
> >experienced and advanced programmers that violating the beauty of the
> >language is unjustified.
> 
> I've been pretty quiet about this lately because the discussions have  
> gone into space, largely by people who don't even have a need or desire  
> for decorators, but uninformed comments like this just irk me.

I don't see anything particularly more uninformed here than in many
other postings.  

I agree to Michel in that we may be trying to fix a slighly inconvenient
but currently nevertheless explicit and easily understandable syntax with
something special cased. 

But is the special case of decorated functions/methods really worth adding a
special case to current syntax rules? 

> Decorators *are not rare* and are *used by regular programmers* in some  
> problem domains.  Yes, it takes an advanced programmer to write such a  
> framework, but that doesn't mean that the syntax is useless to  
> non-advanced programmers.

I have and had lots of use cases where i "decorated" functions --- but i
didn't use the syntax discussed in the decorator threads for it. 
Instead i did something like: 

    cls = transform_methods(cls) 

after the definition of a class.  Which functions are selected to be
transformed by 'transform_methods' is up to you. I used special names as
well as inspecting the first argument name (e.g. 'cls') and other
applicable ideas.  Specifically, in PyPy we use something like 

    def add_List_List(self, w_list1, w_list2):
        ...
    def add_Int_Int(self, w_list1, w_list2):
        ...

and later on just one:

    register_all(vars(), W_ListType)

(which will register the methods to some multimethod dispatcher).  It's
a matter of taste i guess if using decorators - whatever syntax - at each 
function definition would be more readable. 

> It's particularly applicable to applications  
> using PyObjC or ctypes where the function simply will not work unless  
> it's decorated with the correct type signature.  It can also  
> potentially make pure python frameworks such as Twisted, ZopeX3, or  
> PEAK easier to use, by moving boilerplate wrapping stuff into  
> decorators.  Decorators solve a *huge* problem with the current syntax:
> 
> def someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_(takes,  
> some, args, here):
>     pass
> someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_ =  
> objc.selector(someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonge 
> r_, signature='some type signature')

I am not sure the only "good" solution here is to add special decorator 
syntax like ... 

> [objc.selector(signature='some type signature')]
> def someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_(self,  
> some, args, here):
>     pass

for example you could try to use the first line of the docstring 
for it - maybe building on the typical way to document C-defined python
functions. e.g.:

    "(some_type_signature) -> (some_return_type)"

I am not saying straight away this is better but i doubt that the
only good solution to the above problem is to add new syntax. 

> It has nothing to do with being an  
> experienced or advanced programmer, some problem domains simply REQUIRE  
> decorated functions in order to work at all.

But do these problem domains REQUIRE special syntax? I doubt it. 

> If decorators do not make  
> Python 2.4, that is another major release cycle that extensions such as  
> PyObjC and ctypes will be hampered by lack of syntax... to the point  
> where I'd be inclined to just fork Python (or Stackless, more likely)  
> in order to get the syntax.

Nah, just work with us on PyPy to allow it to add decorator syntax
at runtime :-) 

cheers,

    holger