[Python-Dev] method decorators (PEP 318) (original) (raw)

Robert Mollitor mollitor at earthlink.net
Sat Mar 27 08:17:01 EST 2004

On Friday, March 26, 2004, at 04:32 PM, Robert Mollitor wrote:

(Also thinking out loud) How about

def foobar (self, arg): :doc """This is my doc string.""" :author "Guido van Rossum" :deprecated pass Syntactically, I believe this could work, though you would only want it for funcdef and classdef and probably not in single-line suites. So (maybe): defsuite: simpestmt | NEWLINE INDENT decoration* stmt+ DEDENT decoration: ':' test NEWLINE The hand waving justification is that while a ':' at the end of a line or in the middle means "here comes the good stuff", at the beginning of the line it could mean "but first here is an aside".

Oops, that should have been

decoration: ':' NAME test NEWLINE

or along the same lines:

decoration: ':' NAME ':' test NEWLINE

or

decoration: ':' NAME '=' test NEWLINE

Also, these would only be for functions and not classes. Its only the "transformations" that people want or need for classes.

Another idea (leaving exact grammar and exact choice of keywords out of it for now):

def foobar [classmethod] (self, arg) meta:
    :doc """This is my doc string."""
    :author "Guido van Rossum"
    :deprecated
def:
    pass

or

def foobar [classmethod] (self, arg) has:
    :doc """This is my doc string."""
    :author "Guido van Rossum"
    :deprecated
is:
    pass

Here is my take on some recent questions.

Q: Why can't we just accept PEP 318 and just restrict it to non-function-attribute-setting transformations?

A: There is no enforceable way to restrict what the transformations do. People will probably write transformations that simply add attributes to functions, because (1) there will still be a desire to get such settings "into" the function and (2) the old way of "f.author = 'me'" after the function will not work in general when a transformation happens earlier. The second issue in particular is why this PEP needs to be coordinated with a second PEP.

Q: So what if people write transformations that set function attributes?

A: Well, now the issues of size, ugliness, and burying important information come into play. As things currently are there is also the issue of order. Are we prepared to say that the 'classmethod' must come after all the other decorations like 'author', 'release', 'html_version_of_doc'? Now we probably will need to deal with the order issue for transformations anyway, but the solution might make the specification of a new transformation non-trivial. This is ok if the set of transformations is small, but otherwise might mean that the same largish boilerplate is replicated throughout people's codebases.

Q: Why can't we just have a dictionary literal in place of the docstring at the beginning of the function body?

A: Technically, I think we could and that was my first thought, too.
However, I see one big problem with this. Even if we try to educate people (non-advanced python users) that that first bit of code will not actually be placed in the function's code, I still think people will get confused about why function arguments or, say, super() can't be used in that dictionary's definition. These attribute settings need to be syntactically distinct and they may as well be as pretty as possible.

Q: Won't these function attributes just move the code even further from the function name.

A: Perhaps, but it could also provide a useful and not outrageously ugly idiom for lessening it. Consider

class C:

    docstring = """This docstring is really long, maybe even 40 lines

long."""

    def method1 (self, arg):
        :doc docstring
        pass

    docstring = """This is a different string set to the same scratch

class variable"""

    def method2 (self, arg):
        :doc docstring
        pass

Robert Mollitor

More information about the Python-Dev mailing list