Decorators: an outsider's perspective

[Paul Morrow]

Istvan Albert wrote:

> Paul Morrow wrote:
> 
> 
>> That reminds me of how I once thought about using indentation as a 
>> means of denoting code blocks.  How idiotic I thought that was.  Now I 
>> realize the elegance, beauty, 'genius' in that.
> 
> 
> I disagree. In C (Perl, Java etc) we would do three things,
> write braces, indent and put the semi-colon. In python we replaced
> these three, with a single (the most obvious) one the indentation.
> 

And that's the genius there.  Guido (I believe he's the one that came up 
with it) realized that those other symbols were unnecessary.  The 
identation was enough to convey the author's intention.  Now of course 
this wouldn't have been a very good idea if we (developers as a whole) 
used wildly different indentation styles.  But we didn't/don't.  There's 
a conventional way of showing program structure thru indentation that 
the majority of us have always used (subordinate code gets indented).

As Python developers, we have a convention on how we name the first 
formal parameter of instance methods too.  If you write a method that 
follows that convention (uses 'self' as the name of its first parm), 
then you don't need to do anything further to inform your readers that 
it's an instance method.


>> Why don't we all just acknowledge that we are doing this?  Why don't 
>> we all just admit that a well written instance method uses 'self' as 
>> its first argument.  And well written static or class methods (as well as 
> 
> 
> If so then, the logically equivalent solution would be to pass self
> as an implicit parameter, say a named parameter self with a default
> reference to itself. I'm not suggesting this behavior, I only point out
> what I think follows from the first example. The end goal is to
> simplify the behavior not overload it and thus add
> further meaning to it.
> 

No, if self was passed implicitly, then you'ld be back in the situation 
of having to specify (with additional syntax) which methods are instance 
methods.  Less is more.  Python proves that.

> I do agree with Chas Emerick in that encoding special behavior in
> variable names is a fragile solution.
> 

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?