Purely emotional perspective
jeff at ccvcorp.com
Tue Aug 10 02:13:46 CEST 2004
>>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...)
More information about the Python-list