Purely emotional perspective

[Jeff Shannon]

Arthur wrote:

>>I'm particularly worried about the proposals of using this as metadata 
>>for things like author -- that seems to be begging for almost every 
>>function to use half a dozen or more decorators (accepts, returns, 
>>author, design date, last revision date, etc., etc.) which will (IMO) 
>>seriously degrade code readability.  (This syntax is okay for one or two 
>>decorators, but more than that quickly becomes obfuscatory.)
>>    
>>
>
>But isn't that so of any of the alternative syntaxes.  Looks to me as
>if it is." Looks" as in "that is what my eyes tell me".
>  
>

Like I said, I can see the reasons why the alternatives are being 
rejected.  But while I can see why those are being rejected, I'm not 
seeing this one as all that much better -- which suggests to *me* that 
maybe they should *all* be rejected.

I understand that decorators are beneficial.  I understand that "Now is 
better than never."  But I can't help but *also* think that "...never is 
often better than *right* now."  Sometimes *not* including a useful 
feature is better than including it in an ungainly or awkward way.  
(This seems, to my mind, to be especially true of features that are 
principally syntactic sugar, as it seems that @decorators are.)

I know that this has been being discussed for a long time, and nobody's 
come up with a better syntax.  But I remain unconvinced that the 
@-syntax is a significant enough improvement over the current 
(rebind-after-function-body) syntax to warrant a significant change in 
the way that Python code will be structured. 

(It seems, however, that GvR *is* convinced of that very thing, so all 
of this is just whistling in the wind...)

Jeff Shannon
Technician/Programmer
Credit International