On 7/14/09, Carl Johnson <cmjohnson.mailinglist@gmail.com> wrote:
Steven D'Aprano wrote:
The thing about this debate that confuses me is why was the @ decorator ever approved in the first place?
It wasn't, for quite a while. I believe it was proposed for 2.2. I'm sure it was proposed for 2.3. Applying it to classes as well as functions was in the working patch -- but waited until another version just in case.
And yet, @ was approved, in spite of its worthlessness (it literally adds no power to the language, just sugar) and strangeness because of the perceived benefits to readability.
I have a bit of an unusual perspective; I ended up writing some drafts of the PEP, but not because I wanted decorators. Rather, I wanted to avoid a really bad syntax. (@ wasn't my favorite, but it is way better than several of the earlier proposals -- particularly in terms of what it doesn't assume about the future.) Almost any syntax is a big improvement *for*the*relevant*use*cases*. The concern is what it would do to python in general, and which future alternatives it would cut off.
And in my opinion, there are similar cases here, where readability is improved by having the definition of a function come after the expression to which the function will be passed.
Some of the examples looked like the order was an improvement. But are there huge areas where this is needed all over the place? (Extension frameworks such as Cocoa were mentioned for decorators.) Is it useful across several types of programming? (I see it as obvious for callbacks, but maybe not so clearcut elsewhere.) What is the cost of not doing it? With decorators, that cost was often delaying the wrapper for 20-30 lines, and then having to repeat the function name three times, and then using a code style that does confuse some people. In this case, I think the cost of not doing it is more like "Think up a name for the 2-3 line function, and then move the definition up ahead of the usage." Moving the definition is annoying, but not so horrible with small functions, and there is no need to repeat names. (I suppose you could argue that there is one repetition, if the function will never be used elsewhere.) What would the proposed syntax cost? In the case of @, that cost was reduced to burning a punctuation character, and explaining that functions can be annotated -- and the annotation is more than a comment. For the currently proposed syntax, it confuses several issues with suites (blocks). It sounds like the parser can probably handle it, but it isn't as clear that humans can. It might well preclude later block extensions, including more powerful versions, such as thunks or macros. (And it still burns a punctuation character anyhow.)
Yet, there's a lot of resistance to this, and I'm not entirely sure why. If it's just a problem with using "&" and "do" other line-noise and keywords can be proposed to substitute for it.
Yes. Or "using:", of course. The catch is that those are all so generic that this is only one of a zillion possible meanings -- and for most people, not the most obvious. A more specific keyword might have a better chance. (Not a *good* chance -- there is quite a high bar for keywords -- but still *better*.)
$ has no meaning in Python, for example.
I think it starts to with string templates. (And I think "!" is used by some popular extensions, such as scipy, and I think @ interfered with the leo editor, and ...) I'm not saying it is ambiguous to the parser, but the universe of unused ascii-punctuation isn't really all that huge.
If it's the lack of function names and docstrings, there's no reason these lambda-like-thingies can't have support for names and docstrings added (as in my old proposal, for example).
That wouldn't help unless people actually used the names and docstrings -- which again brings up the question about why existing use of functions as first class objects isn't enough.
But I feel like there's some deeper reason people don't think this is a readability win. What is it?
Cost-benefit. It is harder to see the costs, because they're spread out thinly all over the language, while the benefits are concentrated. But those costs are important. In this case, it looks like the benefits are smaller than for decorators, and the costs (at least with the proposed syntax) are higher. And decorators were not a shoe-in. -jJ