[Python-Dev] PEP 318: Can't we all just get along? (original) (raw)

Jim Fulton jim at zope.com
Thu Aug 19 12:29:19 CEST 2004

Bob Ippolito wrote:

On Aug 18, 2004, at 3:42 PM, Kevin Smith wrote:

For what it's worth, I wrote the original PEP 318. I probably wasn't qualified, but I just wanted a nice simple way to declare class methods without having to repeat the function name. After submitting it to BDFL for approval, more work was needed and the discussion of PEP 318 on python-dev increased rapidly. It was evident that I was in over my head, so I asked more someone more experienced to take over.

I guess others had bigger plans for my proposal that I had planned. It has turned into the "solution" to many problems: type checking (both arguments and returned values), metaclasses, metadata, interfaces, function attributes, etc.). Unfortunately, in the process, this simple request for syntactical sugar has turned into a monstrosity. In my opinion, none of the proposed syntaxes really seem Pythonic. This PEP just seems to be trying to solve too many problems. Bear with me, but I'd like to propose one more syntax that is simple, easy for newbies to understand, and nowhere near as powerful as the current PEP's syntax. However, it doesn't add incoherent, arbitrary syntax either. def classmethod foo(x, y, z): pass That's it. One "decorator" that is a callable object that takes a method as it's only argument. No expressions, lists, tuples, etc. Just one callable object. Ok, if you absolutely must have more than one. def classmethod synchronized foo(x, y, z): pass Once again, no expressions. I know that this isn't going to solve everyone's type-checking, metadata, and function attribute problems, but let's face it, using this PEP for all of those things just creates ugly syntax. There must be more Pythonic ways to do those things in their own PEPs. The problem is that there is FAR FAR more use of type-checking, metadata, and function attributes in the wild (from what I've seen and written) than simple stuff like classmethod, staticmethod, and this hypothetical synchronized.

I've never seen anything but classmethod, staticmethod, property and my own "contextmethod" and "cachedproperty", both of which are better served by the simple syntax, in the "wild". The simple syntax serves these uses (yes, excluding write properties) very well. I certainly will use synchronized the the future (I've used something like it in the past.)

I don't think proposals such as this do very much for anyone.

Oh come on. It does a lot for me. IMO, it does a lot for future users of the language by keeping it simpler. Saying that a proposal you don't agree with doesn't do much for anyone is unfair IMO. I think it's pretty inappropriate to devalue arguments just because you don't agree with them.

It's too simple to be useful, and has too many side-effects on existing tools and people that try and read python source :)

Please. Any syntax will have effects on existing source and users. IMO, this obvious syntax best serves the original purpose of the PEP, which is to solve the simple problem if making the syntax of class and static methods sane.

Is @syntax really SO horrible that you propose that we make decorators near useless to most but more "aesthetically pleasing" to some?

IMO, yes, although I'd happily accept both syntaxes. I can live with @foo to server the people who want it, but it bugs me that I have to write:

@clasmethod def foo ....

rather than the, to me, much more obvious and readable:

def classmethod foo ...

Do you use a significant amount of decorators now?

I use class methods and static methods. I use properties a lot, including lots of read properties. I have my own kinds of decorators as well, as mentioned above.

Do you plan to use them much in the future? It seems to me that most people who argue against the sensible and flexible syntaxes are the same people who will rarely if ever use decorators at all...

Well, I use this sort of thing a lot. Most of my uses are served by the simpler syntax. For the uses that aren't served by the simpler syntax, the @foo syntax either doesn't help, as in properties and variations on properties, or doesn't add anything.

Jim

-- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

More information about the Python-Dev mailing list