Decorators: an outsider's perspective

[Chas Emerick]

On Aug 15, 2004, at 2:55 PM, Bengt Richter wrote:

>> Define fragile.  If you mean, easy to break, I don't see it.  There
>> would be only one way to define an instance method: name its first
>> parameter 'self'.  There would be only one way to define a class 
>> method:
>> name its first parameter 'klass' or 'cls' (or some other synoynm that 
>> we
>> can all vote on).  All other methods would be static methods.
>>
>> How is that fragile?
>>
> In a narrow context such as distinguishing between methods, 
> classmethods,
> and staticmethods, ISTM not so fragile. OTOH, generalize the concept 
> too much
> and you get 'hungarian' naming rules as a way of controlling 
> processing.
> Perhaps that is what Chas and Istvan were worrying about.

Ach, that'll teach me to read all the digests in my mailbox before 
mailing to the list :-)  Yes, that's one of the aspects of my worries 
in connection with this proposal.

I wouldn't use 'fragile' to describe the nature of the proposal.  
'Sneaky' is a better one, in that it would be far, far too easy for 
someone to inadvertently make a classmethod without intending to.  The 
decorator approaches to changing a method's type as well as the 
old/current approach of func=staticmethod(func) are both superior in 
this respect, in that they require a distinct intention by the code's 
author.

Another way of looking at this is that the use of an explicit self 
argument was chosen, one can surmise, as a way of making it completely 
clear what is going on in the context of a member function (i.e. better 
to write self.attr=x than just attr=x...I think this is mentioned in 
the python FAQ).  It would run completely counter to that decision to 
now go back and start hanging implicit semantics off of arguments that 
were originally specified for clarity's sake.

- Chas Emerick