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

Bob Ippolito bob at redivi.com
Wed Aug 18 21:51:14 CEST 2004

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 don't think proposals such as this do very much for anyone. It's too simple to be useful, and has too many side-effects on existing tools and people that try and read python source :)

Is @syntax really SO horrible that you propose that we make decorators near useless to most but more "aesthetically pleasing" to some? Do you use a significant amount of decorators now? 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...

-bob

More information about the Python-Dev mailing list