[Python-Dev] method decorators (PEP 318)

[Robert Mollitor]

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):
>
> 	def_suite: simpe_stmt | 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