Decorators: an outsider's perspective

[Bengt Richter]

On Sun, 15 Aug 2004 13:43:30 -0400, Paul Morrow <pm_mon at yahoo.com> wrote:

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

I think I pretty much agree with you (Paul), except that I think the test for
'self' (and analogously 'cls') should be a name.startswith(...) test.
There are a few nested-scope cases where it is necessary to distinguish
two simultaneous and distinct 'self'-parameter bindings, and you need distinct
names to avoid shadowing the outer with the inner. No time to look for the example
I'm thinking of, but I'm sure you can create one (if Peter Otten doesn't beat you to it ;-)

Regards,
Bengt Richter