J2 paper 0.2.1

[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.

---
Greg Chapman