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

[Bob Ippolito]

On Apr 1, 2004, at 3:10 AM, Holger Krekel wrote:

> Bob Ippolito wrote:
>> On Mar 31, 2004, at 3:37 PM, Holger Krekel wrote:
>>> 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.
>>
>> Would you have even considered writing something as crazy as the
>> aforementioned example if decorators were already in Python?  I doubt
>> it.
>
> Yes, we might have have used some decorator syntax.  But then again,
> we also might use full Macros if they were available.  The question
> (to me) is if there are enough use cases to warrant a new special
> decorator syntax.

Well, I would be happy with full macros too.. but I'm not crazy enough 
to propose adding them :)

> At least consider that Python's battery library only has ~10
> occurences of 'classmethod' and no 'staticmethod' at all.

That's a bogus argument, using decorators is currently such a PITA that 
people avoid them, and not much of the standard library was written 
after the release of 2.2.

> And let me add that IMO decorators generally make things harder to
> read because you have to wonder what magic takes place in those
> decorators.  IOW, i am not sure that seeing decorators occurring
> everywhere (because they become so convenient to write) will improve
> readability and debuggability of a python program.

It's not really about readability and debuggability, this is a case 
where the information is absolutely necessary for the program to work 
at all.. the information needs to be there, right up against that def, 
or else it's not readable and hard to debug.  Putting it in a doc 
string and having a metaclass understand how to parse it is not more 
readable and is harder to debug.

>>> 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.
>
> Well, the above is (supposed to be) used for documenting the signature
> of C-functions.  Read "Documentation strings" in

I am *not talking about documentation*!  This is *code*!  It tells the 
bridge how to mangle the input and output of the method when it is 
crossing the Objective C <-> Python bridge!  Without these selectors, 
the code does not work at all, because it needs to convert objects into 
C types (int, float, struct, etc.) and vice versa in many cases.. 
sometimes even worse (pointers, yay!).

-bob