Decorators: an outsider's perspective

[Paul Morrow]

Chas Emerick wrote:
> 
> I think you have the direction of causation reversed here.  Python 
> programmers don't use 'self' as the first argument to indicate an 
> instance method, they/we (again, I worry how much cred I have as a 
> python programmer yet :-) use 'self' *because* a method is an instance 
> method.  I know you'd like the reverse to become a 
> standard/convention...that's a respectable position, but not a 
> particularly practical one since a soon-to-be-standard method for 
> defining a function's type is on its way that just happens to be 
> generalized enough to be useful in tons of other contexts.
>

The "soon-to-be-standard" (gosh, I hope not!) technique would require 
that we explicitly 'declare' class methods and static methods, as we do 
now (albeit with a different syntax).  Isn't that less practical than 
simply having the system enforce the coding convention?  And what 
happens when the declaration disagrees with the convention?  That is, 
what happens when a developer writes

     def foo(self): pass

but declares it to be a class or static method?  Shouldn't the system at 
least issue a warning message (that you're likely to be confusing your 
poor readers)?  And if it's going to go that far... :-)

> I think the source of my gut reaction to the proposal you've advanced 
> (aside from the conceptual action-at-a-distance violation that I already 
> cited) is my past experience with Hungarian notation, where the name of 
> a variable indicates its type.  The comparison isn't totally clean cut 
> because of the special peculiarities of Hn, but I think the folly that 
> it represents is a clear warning to stay away from taking type 
> information based on naming conventions.
> 

I don't see your point about an 'action-at-a-distance' violation. 
Wouldn't that only be the case if something we do locally has side 
effects that break something in another part of the application?

As for the Hungarian notation, I agree that in its most abused state, it 
can be a real mess for all sorts of reasons.   However in Python we do 
use a very lightweight form of that in the way we identify private and 
semi-private methods.

> I won't discuss the virtues or drawbacks of whitespace-as-structure, 
> since that's been hacked to death 1433 times already.  However, I will 
> say that python's usage of whitespace kept me away from seriously trying 
> it for almost a year.  Now, that's absolutely my fault, and isn't 
> representative of the technical ability of python.  However, if 
> continued rapid uptake of python by new users is important, I would 
> suggest that using the success of whitespace-as-structure in 'the 
> market' is not the greatest reference for a proposal.
> 

I said that it was elegant and genius; I never said that is wasn't a 
barrier for adoption.  Still it'll be a sad day when Guido decides that 
to increase Python's popularity, we must support curly braces :-(