[Python-Dev] Re: Call for defense of @decorators
adurdin at gmail.com
Mon Aug 9 07:28:52 CEST 2004
On Sun, 08 Aug 2004 08:25:19 -0700, Guido van Rossum <guido at python.org> wrote:
> This an example of bad formatting. Tests often do that because their
> purpose is to test odd corners of functionality, not serve as sample
> code. Given that in typical example code there will always be a blank
> line separating the decorator from anything previous (and separating
> the body from what follows!) the connection between the decorator and
> the def is pretty clear.
In such a case, it would be clear that the author of the code
considered the decorator and the def to be connected as regards to
their function within the program; that the decorator can
fundamentally alter the meaning of the def statement is not at all
clear -- and it ought to be! By contrast, those proposed syntaxes
which have the decorators in the def statement (somewhere between the
def and the colon) do not suffer this opacity.
> Also note that arguments based on partial knowledge of Python can be
> used as an argument against pretty much anything (just tweak the
> assumptions a bit), and hence have little value.
In the general case, this is probably true; but this argument of mine
is valid for any level of Python user familiar with versions up to
2.3, who has *only* not seen of or heard of the new decorator syntax.
This is because the @decorator syntax has a hidden side-effect, when
compared with normal Python statements. It is not at all consistent
with *any* other valid Python syntax that I know.
Consistency may not always be desirable; but I would have thought it
generally agreed that introducing a severe inconsistency for the sake
of only one feature is not a good design choice. If you believe that
introducing 'new-style' statements/expressions that implicitly affect
what follows them is a good idea *in general*, and is well-suited to
many features other than decorator expressions, then by all means,
introduce it first for decorators, and subsequently for these other
features--but at least let us know *why* these 'new-style'
statements/expressions are a good idea in general (not just for
decorators). Because frankly, and with respect, I haven't seen any
compelling arguments that introducing new statements/expressions with
implicit, non-obvious effects is a good thing for Python. To me, such
a thing reminds me of the horrible implicitly-set $_ and $? (and other
such creatures) in Perl.
Relevant quotes from the Zen of Python (not for argument but contemplation :-)
"Explicit is better than implicit."
"Special cases aren't special enough to break the rules."
"Although practicality beats purity."
"Now is better than never.
Although never is often better than *right* now."
I know you've said you hate the list-after-def syntax. I still hope
that you can change you mind there, or at least reduce "hate" to
"objective reasons for dislike" :-) The latter half of my previous
post was an attempt at this by addressing your stated reasons for
More information about the Python-Dev