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

Holger Krekel pyth at devel.trillke.net
Wed Mar 31 15:37:01 EST 2004

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?

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 = transform_methods(cls)

after the definition of a class. Which functions are selected to be transformed by 'transform_methods' 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 add_List_List(self, w_list1, w_list2):
    ...
def add_Int_Int(self, w_list1, w_list2):
    ...

and later on just one:

register_all(vars(), W_ListType)

(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.

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(someObjectiveCSelectoryesTheyCanBeThisLongsometimesLonge 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.:

"(some_type_signature) -> (some_return_type)"

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.

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.

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

cheers,

holger

More information about the Python-Dev mailing list