Purely emotional perspective

[Bengt Richter]

On Mon, 09 Aug 2004 19:49:38 -0400, Peter Hansen <peter at engcorp.com> wrote:

>Jeff Shannon wrote:
>
>> Personally, I'm seeing more and more usefulness in decorators as the 
>> discussion progresses, and I'm seeing more reasons why the most obvious 
>> alternatives to the currently proposed syntax are not optimal.  But I 
>> still find the current syntax to be *extremely* (painfully) 
>> uncomfortable -- this sort of prefix syntax is unlike anything else *I* 
>> can think of in Python.
>
If the '@' or '|' were a composite glyph instead, and moved a little (to the other
end of the function expression), the "prefix" aspect would look more like
the function call that it is sugar for, e.g., using '(:'

    deco1(:
    deco2(:
    def foo():
        pass
    # ':):)' closing "parens" not required

Thus the order is also plain, i.e.,
    foo = deco1(deco2(foo)))

Or if the colon in '(:' messes up tools, maybe '(%' or '(=' ?
... or '(-;' ?
*<8^P

>That's precisely my feeling at this point as well.  Oddly
>enough, I think with the slight change to use | instead of
>@ (or perhaps even Barry's preferred =) it would be easier to
>swallow.  Fundamentally though it is things like the strangeness
>of these lines that are somehow "bound" to the following (next)
>function definition, yet have no connection to it other than
>coming at the same indentation level.  (At least the | syntax
>does feel like it has a visual "link" to the following def.)
>
>And the reversed order of application (non-intuitive, I feel).
Does (: as above help?
>
>And the restriction to dotted names instead of arbitrary expressions,
>making it feel even more weird and non-Pythonic (and that in spite
>of the workarounds that have been shown for perhaps all cases
>anyway).
Yes. With (: it could be legal as a special function-calling expression trailer
and would call whatever any preceding expression yielded (and obviously fail if
it wasn't callable).

>
>And other subtleties.
>
>> 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.)
>
Some of that sounds like rfc822 stuff ...

>This paragraph also seemed worth leaving in. :-)
>

I'm still wondering what aegis decorators will eventually "unify" under,
and with what ;-) Orthogonality beats special-casing IMO ;-)

Regards,
Bengt Richter