By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,640 Members | 1,581 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,640 IT Pros & Developers. It's quick & easy.

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

P: n/a
Seen on news:gmane.comp.python.devel in message-IDs
<16**********************@montanaro.dyndns.org> and
<16**********************@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
Jul 18 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.