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

[Bob Ippolito]

On Mar 31, 2004, at 3:37 PM, Holger Krekel wrote:

> 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?

Yes.

>> 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.

In the case of PyObjC, the name of the function already has a very  
specific meaning (there is a 1:1 mapping to Objective C selectors) and  
can not change to include type information.  Additionally, it is never  
the case where all methods in a class are to be decorated the same way,  
so it must live elsewhere.

Would you have even considered writing something as crazy as the  
aforementioned example if decorators were already in Python?  I doubt  
it.

>> 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_sometimesLon 
>> ge
>> 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.

Mangling *doc* strings is really stupid and is not even an option,  
IMHO.  The only reason people do this is because we don't have a  
decorator 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.

Special syntax, stupid doc string hacks, or LOTS AND LOTS of ugly  
repetition, as demonstrated.

>> 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 :-)

That'd be an option, if I could wait a few years until it's capable  
enough to do everything it needs to do.  But I can't, which is exactly  
why it's worth forking if decorator syntax doesn't happen in 2.4.  I'm  
just hoping it does, because that requires the least amount of effort  
for everyone :-)

-bob