[Python-Dev] PEP 318 - function/method/class decoration (original) (raw)

Bob Ippolito 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, 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

More information about the Python-Dev mailing list