[Python-Dev] Re: Call for defense of @decorators (original) (raw)
Andrew Durdin adurdin at gmail.com
Mon Aug 9 07:28:52 CEST 2004
- Previous message: [Python-Dev] Re: Call for defense of @decorators
- Next message: [Python-Dev] Re: Call for defense of @decorators
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 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 disliking it.
Andrew
- Previous message: [Python-Dev] Re: Call for defense of @decorators
- Next message: [Python-Dev] Re: Call for defense of @decorators
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]