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

Michel Pelletier michel at dialnetwork.com
Thu Apr 1 12:08:28 EST 2004

I apologize for not changing my digest subjects in earlier messages.

Message: 4 Date: Wed, 31 Mar 2004 19:16:06 -0500 From: "Phillip J. Eby" <pje at telecommunity.com> Subject: Re: [Python-Dev] Re: PEP 318: Decorators last before colon To: Neil Schemenauer <nas-python at python.ca>, python-dev at python.org Message-ID: <5.1.1.6.0.20040331184627.01e86a10 at telecommunity.com> Content-Type: text/plain; charset="us-ascii"; format=flowed

Ugly or not, all of the proposed syntaxes that don't involve creating an extra suite have the practical effect of improving the semantic readability of decorator use over today's Python. In addition, they also have the practical effect of making decorator use more convenient, since the two extra repetitions of the function or class name go away.

Agreed.

I suspect this is part of why there is such disagreement on the subject of decorators: people who make heavy use of them today know exactly what problems today's syntax has from both the readability and writability viewpoints. Whereas people who do not use them, don't get why limiting their use to fixed subsets, or single decorators, or any number of other ideas just negate the usefulness of having a syntax in the first place. Or, like Michel, they don't see a point to having a syntax at all.

I'd like to clarify that I'm not against a new syntax (I'd be more than a bit hypocritical having written two PEPs proposing new syntax!). My original comment was in fact that the line-preceding-def was ugly, not pointless.

My second comment is that I wonder if decoration of any syntax has been thought out in the light of other objects being decorated, like classes, functions, or interfaces. I just feel like there's more thought to be applied here on decoration syntax in general. When we take decoration to the next level, will this syntax suffice? Will it be abused for reasons not considered, like run-time type checking? I'm not positive but it seems this is what Bob I. wants it for.

And have we considered all the options? I'm not making any proposals, but perhaps decoration can be bundled into a separate object that a class refers to, similar to interfaces. This could allow a lot more flexibility and still look like Python. Or perhaps this separate object could be mixed in (blech). But you see my point, the upshot is you could apply different decorations at different times, decorators would be separately managed and it wouldn't look like a shark fin duct taped to a VW bug.

But having said that, I concede: I know that some people make a lot of redundant finger movements working around the lack of decorations. Phillip is right that I don't use decorators (I have used classmethod quite a bit, but that's all) and that he does, so his needs outweigh mine. So I cave. See below for my vote.

Later, Barry said:

So I hacked up python-mode a bit to support the syntax coloring of Guido's previously MFS (most favored syntax). I wanted to see if the concerns about visual obscurity were real or not. Then I rewrote a few methods of mine that would benefit from decorators (with some elaboration). A screen shot of my XEmacs buffer is here:

http://barry.warsaw.us/xemacs.png

Mmm.. I like your colors, it reminds me of a scheme Ken M. shared with me once. I've long lost it, along with his handy pop-to-shell script.

Later, Guido said:

3) Prefix suite (could use a different keyword than 'decorate'):

decorate: funcattrs(foo=42) deprecated overrides classmethod def foo(cls, arg1, arg2): pass

I don't really like it, but it's the only one that looks like Python to me. Otherwise, I vote last-before-colon. Line-preceding-def would be my last choice.

-Michel

More information about the Python-Dev mailing list