While this is nice, I think it somewhat misses the point of Python’s careful syntax debates & decision-making process. Yes, it is good to have the flexibility to do cool stuff (and I'm sure there were ways of getting somewhat decorator-like behavior hacked into Python before decorators), but it's even better when there's a standard, readable, clear way to accomplish whatever cool thing. Then whenever someone needs to do whatever-it-is, they can, easily, and anyone else who comes along will know just what they're doing, and not have to read through whatever code works behind the scenes to make it happen.
IOW, complete flexibility is not the only end goal: adding predictability as well makes the feature twice as nice. There are many possible syntaxes for doing roughly similar things, but if every app uses a different one, life can be hell for whoever has to read the code.
I agree. And it's not that Python strictly needed the "@"-syntax in the first place. They just implemented ("hardcoded", as the article calls it) it to make it obvious what is happening.
4 comments
[ 0.25 ms ] story [ 23.3 ms ] threadIOW, complete flexibility is not the only end goal: adding predictability as well makes the feature twice as nice. There are many possible syntaxes for doing roughly similar things, but if every app uses a different one, life can be hell for whoever has to read the code.
Worth a look : http://blog.rubybestpractices.com/posts/gregory/008-decorato...