[Python-Dev] Re: Call for defense of @decorators (original) (raw)

David Abrahams dave at boost-consulting.com
Mon Aug 9 15:42:31 CEST 2004

Andrew Durdin <adurdin at gmail.com> writes:

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.

Seeing as how we're now firmly back in the land of opinions, voting, and trying to influence the BDFL, I'd like to add:

I agree with Andrew. Whether or not the implementation uses sys.settrace internally, it still feels like it has the same weird, stateful semantics of temporarily affecting the next executable statement and then evaporating.

-- Dave Abrahams Boost Consulting http://www.boost-consulting.com

More information about the Python-Dev mailing list