<16************ **********@mont anaro.dyndns.or g> and
<16************ **********@mont anaro.dyndns.or g> [much material
not-germane-to-my-comments has been clipped]:
def p_statement_exp r:
staticmethod
grammarrule('st atement : expression')
version("Added in 2.4")
deprecatedmetho d
type_(None)
decorate (self, p):
"""docstrin g 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>ne wsguy<MARK>com
