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 disliking it. Andrew
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4