J2 paper 0.2.1

[Steven Bethard]

"Robert Brewer" <fumanchu at amor.org> wrote in message news:<mailman.2180.1093238695.5135.python-list at python.org>...
> The first draft of the J2 proposal is ready. You can read it here:
> http://www.aminus.org/rbre/python/pydec.html

Outstanding job here.  Your arguments are very clear and thorough and
I think you defend J2 against pretty much every objection that was
brought up against it.  I especially liked the point about the
adjectival/dependent uses of keywords already in Python -- I was
undecided about the keyword before, but I could definitely rally
around "using" now.

Minor nits:
* I might write "if/else/elif" as "if/elif/else".  (Google seems to
agree with me -- ~900 hits for the first and ~2700 for the second.)

* The point about expressions (as opposed to statements) occuring only
within suites was a little unclear.  Some things that might help:

1) "Further, it is almost exclusively within suites that one currently
finds [bare] expressions which are not statements."  Just to make sure
we're not confusing expressions in, say, the test of a while-loop,
with the use of /bare/ expressions you're talking about here.

2) Make clear that you are talking about /standard/ usage of
expressions -- I can, of course, write an expression like, say, a list
comprehension, at the top of any module I like, but I'm not very
likely to do so.  That is, Python /allows/ expressions pretty much
anywhere, but they aren't generally /used/ everywhere.

3) "Lambdas are another common example, albeit degenerate, of [a suite
containing] bare expressions."

4) It's a little unclear what "consequently" is referring back to. 
Maybe:
"[Given this precedent for using expressions in suites and the lack of
such precedent for non-suites,] a suite is a more appropriate and
consistent place (than normal linear code) in which to introduce a
series of decorator expressions."

* Tie the reasons for recommending "using" back a little more tightly
to the new keyword requirements above it:

1) "It emphasizes the dependent nature of decorators[, both in its
semantics and in its inability to 'stand alone' without the def
statement]."

2) "It 'reads correctly' in every use case, both for transformational
and annotative decorators."  (This one actually seems a lot like "It
emphasizes the generic nature of decorators."  Maybe a few more words
on what you mean by "generic" to explain the differences here?)


Well, thanks again for such outstanding work in such little time!

Steve