[Python-Dev] PEP 318 - function/method/class decoration
bob at redivi.com
Fri Mar 5 15:23:00 EST 2004
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,
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
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.
Practical domain specific examples for PyObjC:
def doOpenFileService_userData_error_(self, pboard, data)
# this is a PyObjC example, in this case, doServiceSelector would be a
# decorator that does:
# doOpenFileService_userData_error_ =
# this wrapping is ABSOLUTELY NECESSARY since this selector is called
# 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]:
def insertObject_inFooAtIndex_(self, obj, index) [objc.accessor]:
I can create practical examples for other domain specific Python
frameworks (PyProtocols, PEAK, ctypes, etc.) if that is necessary to
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
... 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.
More information about the Python-Dev