[Decorators] Seen on pydev -- comments on such.

[Richard Hanson]

Seen on news:gmane.comp.python.devel in message-IDs
<16668.57809.362313.36355 at montanaro.dyndns.org> and
<16669.7113.531528.462699 at montanaro.dyndns.org> [much material
not-germane-to-my-comments has been clipped]:

>    def p_statement_expr:
>        staticmethod
>        grammarrule('statement : expression')
>        version("Added in 2.4")
>        deprecatedmethod
>        type_(None)
>    decorate (self, p):
>        """docstring here"""
>        print p[1]
>
> [...]
>
>    * It doesn't put the cart before the horse by introducing the decorators
>      before the def.
>
> [...]
>
>    * It doesn't add an extra level of indentation to the function body.
>
> [...]
>
>    * It looks more like current Python block structure (at least to me)
>      than the @-syntax proposal.

Allow me to expand just a bit on the bullet immediately above
from Skip's list of pros for his proposal:

    * It looks like the standard "backwards-'F'" block shape
      which, for example, try-except, try-finally, and if-else 
      already use. 

(I think this point had been mentioned, prior, and I apologize
that I don't have that post at hand. Also, Skip is probably
alluding to my very point.)

I'm a relative newbie to Python (and only a hobbyist as I've been
retired for almost two decades). I discovered Python only a few
years ago. Like many, I don't have all that much time or energy
or both to devote to active learning of Python, and how the
herein quoted proposal fits my brain may mirror a not
insignificant minority of the Python-using community. 

I hadn't even heard of the decorator concept (as Python renders
it) until discussion about such cropped up on pydev (and here)
over the last while (last year?) or so. I soon grokked what they
were about. And -- I seemed to find no problem whatsoever with
the 2.4a2 prefix @deco form.

Yet, opposition from much-more-learned-than-me folks made me stop
and think. When Guido himself recently opened the door
just-a-crack (on pydev) to another decorator-form *if* the
community could come up with *one* (he may have said two...?)
alternative(s) which were persuasive to him, I sat up.

While I trust the developers, and particularly Guido (I have no
rational argument to support such religious veneration <wink>),
to resolve this in a fine manner, I would like to say the
alternative quoted above fits my newbie-but-not-too-dumb :-)
brain just as smoothly as the currently implemented, prefix @deco
form. It may even be smoother for "newer" newbies.

As I pondered the visual appearance of the above quoted
"backwards-'F'" form of decorated functions, the common
try-except, try-finally, and if-else block-forms came to mind,
and I thought: No problem. Decorated functions (or, perhaps,
decorated some other things) are just another one of the
"backwards-'F'" visual wetware shape-templates (the other common
Python shape-template being the "backwards-and-upside-down-'L'")
for my brain to pattern-recognize.

Therefore, for me, the backwards-F form is not a negative. (And
better backwards-F forms may yet evolve.) I recognize, however,
that other considerations may well still outweigh the "shape"
argument.

---

Having said all that, I'll add that I'm hardly qualified to
comment at all on the Shape Of Things To Come :-), and I'll
happily and gratefully use any decorator form (if I figure out
Python well enough to use them <wink>). I just couldn't resist
throwing in my own thoughts on the topic (as it appears we're
going for the All-Time Longest Topic Ever Award <very big wink>).

(I haven't learned the <x.x wink> syntax, yet... :-) )

brain-oriented-visually-y'rs,
Richard

-- 
R Hanson [The mangled email addie below works.]
sick<P0INT>ole<PERI0D>fart<PIE_DEC0_SYNTAX>newsguy<MARK>com