Are decorators really that different from metaclasses...

[Jeff Shannon]

Arthur wrote:

>"Jeff Shannon" <jeff at ccvcorp.com> wrote in message
>news:10jcsuh7k4bfl41 at corp.supernews.com...
>  
>
>>(I'm sure that you'll argue that the presence of those "magic" variables
>>is enough distinction between the two radically-different blocks of
>>code; I'm also pretty confident that very few people will agree with
>>you, and that nobody with a reasonable understanding of Python internals
>>will be among those few people.)
>>    
>>
>
>It seems to me if the defining distinction is a different assignment
>operator rather than magic associated with naming, then much of objections I
>am hearing to what Paul is generally suggesting seems to fall away.
>
>I like what Paul Rubin suggested for decorators:
>
>::
>
>It seemed to me that many folks, and certainly including some sophisticated
>users - witness the decorator wiki - felt more than comfortable with some
>declarative/definitional syntax within the function body.  The discussion
>was stalled mostly by the realization that Guido had definitively ruled it
>out, not on the basis that there was general concensus that the approach had
>no appeal - intuitive and otherwise.
>  
>

I agree with what Paul Rubin says there, as well.  However, I don't 
believe that he was considering syntax that *looks* like 
otherwise-ordinary assignment to "magic" names, which are indicated only 
by naming convention.  Docstrings don't look like part of the function 
body, because they don't look like otherwise-normal statements.  
Suitably-indicated decorators (even @decorator) inside a def wouldn't 
(IMO) look like part of the function body, because they too would not 
look like otherwise-normal statements.  On the other hand, this "magic" 
proposal of Mr. Morrow's *does* look like otherwise-normal statements -- 
the only difference is the use of a particular naming convention.  And 
to make matters worse, in other contexts the assignment to identifiers 
following that same naming convention would have *completely* different 
semantics (i.e., the current semantics).

What we have are two orthogonal elements ( __*__ naming conventions and 
the assignment operator) which currently have very well-defined and 
predictable meanings.  Paul's proposal would create a case where, *if* 
you use those two elements *together*, in a *particular* syntactic 
position, then suddenly their meaning is radically changed -- but only 
in that particular position.  That kind of special-case behavior is a 
major violation of the principle of least surprise, and is virtually 
guaranteed to lead people to all sorts of confusion -- meaning bugs, 
wasted time figuring out what *should* happen, etc, etc.

Jeff Shannon
Technician/Programmer
Credit International