[Python-Dev] Re: PEP 318: Decorators last before colon (original) (raw)

Bob Ippolito bob at redivi.com
Wed Mar 31 16:01:16 EST 2004

On Mar 31, 2004, at 3:37 PM, Holger Krekel wrote:

Hi Bob,

Bob Ippolito wrote: On Mar 31, 2004, at 1:59 PM, Michel Pelletier wrote:

Please don't add any decorator syntax to Python, at least not yet. All of the proposals I have seen so far are, to be blunt, and in my opinion of course, ugly and are getting uglier as the discussion ensues.

I see nothing wrong, at least for the present, with the status quo decorators that follow a function or class definition. They are explicit, functionally equivalent, use the existing and completely understandable syntax, and are so rarely used by only the most experienced and advanced programmers that violating the beauty of the language is unjustified. I've been pretty quiet about this lately because the discussions have gone into space, largely by people who don't even have a need or desire for decorators, but uninformed comments like this just irk me. I don't see anything particularly more uninformed here than in many other postings. I agree to Michel in that we may be trying to fix a slighly inconvenient but currently nevertheless explicit and easily understandable syntax with something special cased. But is the special case of decorated functions/methods really worth adding a special case to current syntax rules?

Yes.

Decorators are not rare and are used by regular programmers in some problem domains. Yes, it takes an advanced programmer to write such a framework, but that doesn't mean that the syntax is useless to non-advanced programmers. I have and had lots of use cases where i "decorated" functions --- but i didn't use the syntax discussed in the decorator threads for it. Instead i did something like: cls = transformmethods(cls) after the definition of a class. Which functions are selected to be transformed by 'transformmethods' is up to you. I used special names as well as inspecting the first argument name (e.g. 'cls') and other applicable ideas. Specifically, in PyPy we use something like def addListList(self, wlist1, wlist2): ... def addIntInt(self, wlist1, wlist2): ... and later on just one: registerall(vars(), WListType) (which will register the methods to some multimethod dispatcher). It's a matter of taste i guess if using decorators - whatever syntax - at each function definition would be more readable.

In the case of PyObjC, the name of the function already has a very
specific meaning (there is a 1:1 mapping to Objective C selectors) and
can not change to include type information. Additionally, it is never
the case where all methods in a class are to be decorated the same way,
so it must live elsewhere.

Would you have even considered writing something as crazy as the
aforementioned example if decorators were already in Python? I doubt
it.

It's particularly applicable to applications using PyObjC or ctypes where the function simply will not work unless it's decorated with the correct type signature. It can also potentially make pure python frameworks such as Twisted, ZopeX3, or PEAK easier to use, by moving boilerplate wrapping stuff into decorators. Decorators solve a huge problem with the current syntax:

def someObjectiveCSelectoryesTheyCanBeThisLongsometimesLonger(takes, some, args, here): pass someObjectiveCSelectoryesTheyCanBeThisLongsometimesLonger = objc.selector(someObjectiveCSelectoryesTheyCanBeThisLongsometimesLon ge r, signature='some type signature') I am not sure the only "good" solution here is to add special decorator syntax like ... [objc.selector(signature='some type signature')] def someObjectiveCSelectoryesTheyCanBeThisLongsometimesLonger(self, some, args, here): pass for example you could try to use the first line of the docstring for it - maybe building on the typical way to document C-defined python functions. e.g.: "(sometypesignature) -> (somereturntype)" I am not saying straight away this is better but i doubt that the only good solution to the above problem is to add new syntax.

Mangling doc strings is really stupid and is not even an option,
IMHO. The only reason people do this is because we don't have a
decorator syntax.

It has nothing to do with being an experienced or advanced programmer, some problem domains simply REQUIRE decorated functions in order to work at all. But do these problem domains REQUIRE special syntax? I doubt it.

Special syntax, stupid doc string hacks, or LOTS AND LOTS of ugly
repetition, as demonstrated.

If decorators do not make Python 2.4, that is another major release cycle that extensions such as PyObjC and ctypes will be hampered by lack of syntax... to the point where I'd be inclined to just fork Python (or Stackless, more likely) in order to get the syntax. Nah, just work with us on PyPy to allow it to add decorator syntax at runtime :-)

That'd be an option, if I could wait a few years until it's capable
enough to do everything it needs to do. But I can't, which is exactly
why it's worth forking if decorator syntax doesn't happen in 2.4. I'm
just hoping it does, because that requires the least amount of effort
for everyone :-)

-bob

More information about the Python-Dev mailing list