J2 paper 0.2.1

[Robert Brewer]

The first draft of the J2 proposal is ready. You can read it here:
http://www.aminus.org/rbre/python/pydec.html

At this point, I am looking for comments regarding the proposal. Once I
believe I have addressed a sufficient number of concerns, I will freeze
the document and call for signatories, both for and against, then send
it to Guido. Until that time, expect the draft to change multiple times
each day (there's a meta tag with the version number if you care to
check).

In this thread, please do not introduce discussions regarding syntaxes
other than J2 and A1. Limit your comments to the three arguments,
literary critique, and praise for Mr. Sparks who is providing the
implementation. Oh, and somebody let me know if you rampaging lot crush
my little server.


Robert Brewer
MIS
Amor Ministries
(e-mail address removed)

 

[Nigel Rowe]

The first draft of the J2 proposal is ready. You can read it here:
http://www.aminus.org/rbre/python/pydec.html

At this point, I am looking for comments regarding the proposal. Once I
believe I have addressed a sufficient number of concerns, I will freeze
the document and call for signatories, both for and against, then send
it to Guido. Until that time, expect the draft to change multiple times
each day (there's a meta tag with the version number if you care to
check).

In this thread, please do not introduce discussions regarding syntaxes
other than J2 and A1. Limit your comments to the three arguments,
literary critique, and praise for Mr. Sparks who is providing the
implementation. Oh, and somebody let me know if you rampaging lot crush
my little server.


Robert Brewer
MIS
Amor Ministries
(e-mail address removed)

It's a *very* minor nit (which just indicates how much basic agreement I
have with the document overall), but, could the list of example keywords be
put in alphabetical order?

Ie:

predef, prologue, preamble, preface, helper, amend, using, having, qualify,
extend, confer, meta, through, per, via, by

becomes

amend, by, confer, extend, having, helper, meta, per, preamble, predef,
preface, prologue, qualify, through, using, via

 

[Colin J. Williams]

Congratulations. This is an impressive piece of work, done in a short time.

I prefer this proposal to the existing implementation.

I hope that someone will prepare as thoughful a piece on one of the C
options. I would prefer C2 with uses as the keyword.

Since the 'decorator' is a modifier, it would make better sense for the
modification to come after one has identified what is to be modified.

One nit picking comment on Robert Brewer's document: An annotation is a
transformation of a function, as a change to the flow of control is.

Colin W.

 

[Paul McGuire]

Beautiful work - where do I sign? (as a supporter, of course)

-- Paul

 

[Steven Bethard]

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

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Steven Bethard]

[Robert Brewer]

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.

All superb indeed. Congratulations, and thanks.

Thanks also to Michael for the implementation, and to Paul who helped us all
at channelling the conversation.

 

[Greg Chapman]

Note that this:

<token>:
memoize
classmethod
synchronize
funcattrs(author="Guido van Rossum")
def foo(cls, *args):
pass

is probably broken, at least given most of the proposed implementations, in
which classmethod and staticmethod would have to be either first or last. I
suppose one could automatically detect them and move them to the proper place.

Also this:

"In contrast, the current Python decorator proposal provides the exact
opposite--all decorators accept one function and return one function. Although
they are not required to return a new function, or change function signatures or
calling semantics, many will, including the most common decorators, classmethod
and staticmethod."

is wrong in that classmethod and staticmethod do not return functions (or even
callables), which is why they have to be in a special place.


The asymmetry between classmethod/staticmethod and other proposed decorators has
been bothering me for a while. It seems to me that it might be better to extend
the def statement to allow (e.g.):

funcdef: [decorators] 'def' [NAME] NAME parameters ':' suite


where the first (optional) NAME above would match either "class" or "static":
anything else would cause the compiler to generate a SyntaxError (the idea is to
have context-senstive keywords like the "as" in imports. Of course, "class" is
already a keyword; if this causes problems, one could use e.g. "classdef"). The
implementation (in com_funcdef) could either emit a new opcode (e.g.,
MAKE_DESCRIPTOR) after the decorator CALL_FUNCTIONS, or it could emit a
LOAD_GLOBAL (for classmethod or staticmethod) before com_decorators and an extra
CALL_FUNCTION after the decorator CALL_FUNCTIONS.

As I see it, the advantages of special treatment for classmethods and
staticmethods are 1) it removes the need to make sure they are declared in the
proper position among a list of decorators, 2) it is somewhat analogous to the
way static is used with methods in C# and Java (where it is part of the function
signature and not of any metadata) and 3) in most cases, it will remove the need
for the special decorator syntax (to be honest, I find all of the proposals
fairly ugly).

I'm sorry if this has been proposed before (I haven't had time to follow all the
discussions); it does not appear to be one of the options in the wiki, so I
thought I'd throw it out.

 

[David Pokorny]

Robert,
I think the proposal is fantastic. Very thorough and positive.

Choice of Keyword:
+1 for 'using'

Grammar:
In another thread (J2 proposal: keyword), we came to some synthesis on
allowing semicolons to separate decorators:

+1
Nicolas

This is a much better idea than what I had originally suggested, and there
is some precedent, namely the simple_stmt form (from Grammar/Grammar).

simple_stmt: small_stmt (';' small_stmt)* [';'] NEWLINE

An argument against allowing this: it can lead to some mild abuse, namely

From what I can tell, this is about as bad as it gets as for readability. I
see two rebuttals to this example:

A) accepts(...) and returns(...) are just stopgap measures for what may be
the "optimal function prototype syntax" (I can hear the groans already).

B) As a matter of philosophy, Python both creates the infrastructure to make
readable programs and encourages good coding style that leads to readable
programs but does not actually force you to write readable programs. I think
disallowing the following

would be an unjust fate for a decent compromise between readability and
economy.

---------------------------------------------------
One possible syntax, which mimics Grammar/Grammar:

small_decorator: dotted_name [ '(' [arglist] ')' ]
simple_decorator: small_decorator (';' small_decorator)* [';'] NEWLINE
suite_of_decorators: simple_decorator | NEWLINE INDENT simple_decorator+
DEDENT
funcdef: ['SpanishInquisition' ':' suite_of_decorators]
'def' NAME parameters ':'suite

David

 

[Paul Moore]

The first draft of the J2 proposal is ready. You can read it here:
http://www.aminus.org/rbre/python/pydec.html

At this point, I am looking for comments regarding the proposal. Once I
believe I have addressed a sufficient number of concerns, I will freeze
the document and call for signatories, both for and against, then send
it to Guido. Until that time, expect the draft to change multiple times
each day (there's a meta tag with the version number if you care to
check).

I have just read this - it's a very good document. I don't necessarily
agree with all of it, and I'm not sure I'm convinced by it, but it
makes a solid proposal to submit.

Some comments:

1. I differ on the "it doesn't matter what the keyword is" statement.
On the contrary, my view could completely change depending on the
keyword - I'd loathe "predef", whereas "using" is acceptable to me.
Putting the proposal forward *without* an agreed keyword isn't
(IMHO) fair to people who have this view.
2. I agree with the person who pointed out that the indentation makes
the decorators merge visually with the function name. This is a
definite point against the syntax, and should be at least noted in
section "Arguments - I - 3 Additional benefits" paragraph 2. In
fact, I could esily argue that it completely invalidates this
point, swinging it in favour of @ syntax.

Also, I'd say that the proposal needs to be submitted with a full,
working patch. This isn't meant to be sour grapes, but I'd be
concerned if the proposal was submitted, Guido approved it, and then
it wasnt't possible to get a working version ready in time for the
next alpha. Regardless of any other consideration, I'm completely
against any delay of the 2.4 timescales for this.

From a brief reading of the description attached to the current patch,
I have a couple of comments:

1. The patch doesn't (according to the comment) implement the
__future__ import. This needs to be added before the proposal is
submitted. And __future__ support for the interactive prompt may be
needed as well - I'm not sure here, see PEP 236 for the detail.
2. Does the patch support decorating classes? The @ syntax *might* by
now (in CVS), there was discussion of adding it but I'm not sure it
went in. The patch should probably provide the same functionality
as CVS @-syntax, rather than just 2.4a2.

Having said all this, I'd have to say that I'm still not sure I'm
swayed. I'm only ever going to be an occasional user of decorators, I
suspect, so I don't really care a *lot*, but I think I still prefer @
decorators.

Paul.