Lambda the Ultimate

seem to be the latest thing on all the Python lists at the moment. I've been using the old syntax (someFunction = synchronized(someFunction) for decorators for a little while now, and I think the new syntax is a slight improvement. Beyond that, I'm not sure there's much to say. But it appears that quite a few people feel differently about that...

The debate on c.l.p has been intense. Is it Pythonic or Perlish? At-signs or square-brakets? Is "decorator" misleading because of the design pattern with the same name? Should the decoration go before the function definition, on the same line as the "def", or on the next line with the docstring? Or should a totally different syntax be used? Well, there's already one in the alpha. Some people seem to like it. Why not try it out? Do you have a visceral reaction to it? Does it look like Perl? Is the at-sign thing just a keep-up-with-the-Joneses attempt at mocking the new Java? Was it just convenient to implement? How would you do it differently? Should we have a vote? Do the results of the vote matter if people that want things the way they already are would be less likely to vote?

It's just so noisy. I don't care, I mean, I'll love Python whichever way it goes. I probably won't even use the feature unless I have to, and if Jython is still stuck at 2.1, I'll mostly have to avoid them just to keep my code portable anyway.

But what really bugs me is that somebody should just make a decision, people should respect that decision, and we should move on. I really wish Python had gotten a ternary operator; having to abuse "and" and "or" just to embed a conditional in an expression is tacky. I don't care what the syntax is! Pick one! I feel like that feature died because of the noise, because nobody could agree on anything, and if that's the direction of Python's future, it's a little bit scary.

Look, we're not all going to agree on anything. I thought that's why Guido was chosen as "Benevolent Dictator for Life". Lately, his strategy has been to say something like "Well, I don't care if we add the feature, and I don't care if we don't, but if you all can decide on a syntax, we'll do it." I think that this approach is killing progress. Of course we won't all agree. We're a bunch of opinionated hackers, and we like things our way. That's why you're dictator, Guido. Dictate!

Language is the one concrete dependency that we never seem to be able to abstract away. Changing a language affects more people the more successful a language becomes. Is it the destiny of every language to eventually grind to a halt, for no other reason than people's inability to agree on the next step for growth? I hope not, but I'm glad we have lots of other languages that are not so constrained.

This is really not intended as flame-war, despite my critique...

My article about Python Declarators's

It's about modifying the Ruby interpreter (only one line needs to be changed) to allow Python-like (forward declared) decorators in Ruby.

Of course it does not have the full power of Python decorators (e.g. you cannot pass parameters without surrounding the method definition with parens).

Isn't an Aspect-oriented approach in general better suited? IMO, Aspects in general have a lot of other advantages.

Another problem with the decorator approach in Python is, that it doesn't work for many methods at once. E.g. if you want to declare 10 methods to be synchronized, you have to write 10 times "@synchronize". In Ruby for example, the "public/private" methods, which are methods and not keywords, are able to do this. They make all following method declarations public (or private). You could do the same for "synchronized" of course.