> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4