[Python-Dev] Re: Call for defense of @decorators

[David Abrahams]

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