[Python-Dev] PEP 318 - function/method/class decoration

[Bob Ippolito]

I don't want this topic to be forgotten about, again, because it's 
extremely important to the practicality of domain specific uses of 
Python (such as PyObjC, ctypes, etc.) but can also have positive 
effects on the rest of Python (for example, people will actually use 
descriptors where appropriate, metaclasses will be abused less often, 
etc.).

What's good:
	It has the possibility to bring some of the alternate python compilers 
back to Python-compatible syntax (Quixote, Pyrex, etc.)
	It's the only reasonable way of transforming the result of a "def" 
block (adding metadata, such as interface compliance, or changing 
behavior, as in staticmethod).
	When extended to class definitions, it can put an end a lot of 
__metaclass__ and stack introspection abuse.
	It doesn't break anything, because you don't have to use the extended 
syntax.

What's bad:
	A syntax has not been definitively chosen.  The PEP itself is too 
vague on this point.

I propose that we just go with the syntax we *already have an 
implementation for*.  I don't see anything wrong with it, I believe it 
is the most popular, and I personally don't like new keywords.  I have 
also committed to doing whatever needs to be done to get this into 
Python 2.4 (writing documentation, examples, etc.), but I obviously 
can't do that until we have decided which syntax wins (though this one 
is my preference, for practical and aesthetic reasons).  I don't have 
infinite free time, so the sooner the decision the better.  In other 
words, I think it is *extremely* counter productive to keep bringing up 
the topic of other ways to spell this.  I would like to focus this 
thread to, specifically, if *this syntax* should become part of Python. 
  It is already clear the the idea of function/method/class decoration 
is worthy.  When you give your -1,+0,+1 etc, please do it ONLY for this 
syntax, and do NOT vote based upon the *idea* if and only if combined 
with another syntax (without brackets, brackets on the left, keywords, 
ampersands, dollar signs, I don't care - please - don't bring them up).

This proposed new syntax is:

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

	classdef: 'class' NAME ['(' testlist ')'] ['[' exprlist ']'] ':' suite

Entirely too trivial examples are as follows:

	def addArgumentsTogether(*args) [staticmethod]:
		return reduce(operator.add, args)

	class ClassUsingDocTests(object) [UseDocTests]:
		"""
		This could potentially modify the class instance to use doc tests,
		contracts, or what have you.. without adding a nasty __metaclass__,
		that can cause problems when subclassing, etc.
		"""
		pass

Practical domain specific examples for PyObjC:

	def doOpenFileService_userData_error_(self, pboard, data) 
[doServiceSelector]:
		# this is a PyObjC example, in this case, doServiceSelector would be a
		# decorator that does:
		#
		# doOpenFileService_userData_error_ = 
objc.selector(doOpenFileService_userData_error_, signature="v@:@@o^@")
		#
		# this wrapping is ABSOLUTELY NECESSARY since this selector is called 
from ObjC
		# and uses a NSObject ** that must be set if an error occurs.  Since 
this is a custom-named selector
		# and doesn't come from a protocol, then PyObjC can't possibly know 
what selector to use by the name alone (without heuristics)

	#
	# the accessor wrappings are also ABSOLUTELY NECESSARY to participate 
in Key Value Coding,
	# because they take non-object arguments and are called by ObjC.
	#
	def objectInFooAtIndex_(self, index) [objc.accessor]:
		return self.myFoo[index]
	
	def insertObject_inFooAtIndex_(self, obj, index) [objc.accessor]:
		self.myFoo.insert(index, obj)

I can create practical examples for other domain specific Python 
frameworks (PyProtocols, PEAK, ctypes, etc.) if that is necessary to 
convince people.

Please, "import this" before you decide to -1 or -0.. specifically:
... Simple is better than complex.
... Flat is better than nested.
... Although practicality beats purity.
... There should be one-- and preferably only one --obvious way to do 
it.
... Now is better than never.

I would love to see a decision by PyCon.  I will dedicate some of my 
sprint time on documentation, tests, implementation tweaks, etc. for 
this new syntax if it is accepted.

-bob