[Python-Dev] Re: PEP 318: Decorators last before colon (original) (raw)
Guido van Rossum guido at python.org
Mon Apr 5 00:33:38 EDT 2004
- Previous message: [Python-Dev] Re: PEP 318: Decorators last before colon
- Next message: [Python-Dev] Re: PEP 318: Decorators last before colon
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
There are different kinds of aesthetics. Guido's proposal has grown on me from a visual aesthetics point of view. After I worked with it a little bit, I realized it really is much prettier than decorators-before-colon.
Right. It really is.
However, from more intellectual aesthetics (consistency, predictability, etc.) I still dislike it, and don't really see how to sanely reconcile it with the Python syntax of today. I wish that I did, because it really does look better for simple decorators.
I, too, wish that there were a way to make it work with current expectations. The * prefix looks so arbitrary: why not /, why not @, etc...
On the other hand, no syntax proposed so far has been really that nice to look at when used for multiple decorators.
Yet, decorator-before-def does better there, too, because it gives you more horizontal space to work with. This is useful for decorators that take argument lists, like the ObjC decorator and I believe some of PEAK's decorators. (I don't want to use funcattrs() as an argument here, because I believe that it is simply an inevitable by-product of introducing any kind of decorator syntax -- while far from perfect, in terms of readability setting function attributes in a decorator is so much better than setting them after the function has been defined, that I believe we have no choice but to provide it. (Similar for synchronized, except I feel less pressure to add it; I'd much rather introduce some kind of general block wrapper feature like we have discussed many times here.))
I also note that accepting decorator-before-colon now would make it harder to come up with a decent syntax for declaring the return type, which I still want to do in some future version of Python with optional (!) static typing. But not impossible -- there's enough punctuation available besides '[' and ':'.
I also note that the proposed variants that prefix the 'def clause' with another (optional) indented clause, started e.g. by 'with:' or 'decorate:', look much worse. They violate another strong expectation in Python: that a suite is a sequence of statements. (And it really can't be a sequence of statements -- e.g. assignments just really don't make sense as decorators, nor do many other forms of statement.)
One worry about every syntax that supports multiple decorators: as soon as there's a transformation among the decorators, they stop being commutative. And that could cause a load of problems with beginners trying their hand at using complicated decorators (e.g. trying to define a class property by combining classmethod and property).
--Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] Re: PEP 318: Decorators last before colon
- Next message: [Python-Dev] Re: PEP 318: Decorators last before colon
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]