[Python-Dev] Re: PEP 318: Decorators last before colon

[Michel Pelletier]

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