Otaku, Cedric's weblog

It seems that matz made that comment in May 2005, which is not exactly three years ago ...

Indeed, Stefan. I hadn't noticed Matz commented on the entry two years after I posted it :-)

I stand corrected.

I'm not as convinced Python is going to die out and be replaced by Groovy any time soon. The former has a number of years in the field, whereas Groovy doesn't even have a decent parser. The lambda problem might be a problem for Python, but Groovy has even worse handling of general syntactic sugar.

I agree with your idea on domain specific languages, though. Isn't it strange how no matter where you start, you evolve towards Smalltalk?

Some good points, but here's a small correction: Python does have lambdas. The rejected proposals are for *multi-line* lambdas. One practical effect of Python's current lambda rules is to limit their size. I think that the party line is that this usually makes things more readable, and therefore more "Pythonic".

Doug, correct me if I'm wrong but as far as I understand "lambdas" in Python aren't real closures, that is they don't carry their lexical scope at instantiation around with them. That makes them a lot less useful.

I agree with you Cedric (for once ;-) ), I don't think Python has much for it in the competition of dynamic languages. It did once, but age has not treated Python well.

Python lambdas are real closures, but they are single expressions, not statements.

Python has some very interesting features that only Haskell also has: list and generator expressions.

There are problems with Python, but there are also problems with Ruby. The confusion over whether local variables first used in a block are created in the method scope or limited to block scope for example. Blocks in Ruby aren't real objects and you have to use ugly "lambda" or "proc" functions to turn them into objects. Also, the usefulness of blocks in Ruby is greatly diminished by Ruby's parenthesis-and-commas syntax for method calls compared to Smalltalk's keyword-argument syntax or the minimal syntax of LISP and functional languages.

Hi Anonymous,

Ruby has named parameters using the hash notation:

Person.new({:firstName => "Cedric", :lastName => "Beust"})

Anyway, this entry is not about comparing languages but about discussing the ability of Python to evolve.

> Person.new({:firstName => "Cedric", :lastName => "Beust"})
You don't need put them in {}. If you do, it's just a hash literal you're passing.

For keyword arguments use this format, that is without braces:
Person.new(:firstName => "Cedric", :lastName => "Beust")

Haskell has an elegant solution to this problem: the language is defined in terms of curlies and semicolons, but if you use whitespace they are optional. So it has the nice spare layout of Python normally, but when you need a multiline whatever you just stick in the appropriate braces.

I don't think meaningful indentation is a problem in evolving a language much more than any other specific syntax rule.
Python has evolved a lot in semantics even if just slightly in syntax, but there is quite a bit of new stuff there too.

For example, ruby's special cased one-function-argument syntax makes it harder to provide multiple blocks as in Smalltalk, or think of how hard adding a pythonic/javaish stackable function decorator syntax with arguments would be.

I think meaningful indentation may be a slightly more pesky problem, but not really much.

As for the "python lambdas are not closures" python lambdas do carry their environment, the problem is you can't use assignment in lambdas, and even using nested functions when you try to reassign to a variable that you got from an outer scope you'll create a new local one, i.e.:

>>> def exp(num):
... def f():
... num= num * num
... return num
... return f
>>> powers_of_two=exp(2)
>>> power_of_two()
Traceback (most recent call last):
File "", line 1, in ?
File "", line 3, in f
UnboundLocalError: local variable 'num' referenced before assignment

which is different from any other closure system I'm aware of.

Cedric,

All due respect. I'm no Python zealot, but you seem to be conflating syntax with implementation. Python has a rock solid implementation. Guido's conservatism is to be applauded. You can't just give the kids every toy that they want.

I was never a proponent of the lack of curly braces in Python, but I respects Guido's stubborness and the Python community is growing, not shrinking.

In fact more and more of us are thinking less in terms of languages. I need a rock solid implementation, though, and in that respect Perl is superior to Ruby.

As a newcomer to ruby, the "killer app" is rails - I'm looking at the whole language due to that one application. I'm from a Perl background, with 10 years now as a sys admin using perl for everything. Python has never interested me, due to the incompressible syntax - usually my programs start and end life as 1-line hacks. Of course the larger programs are well-structured and indented, but it's orthogonal. So far, perl is still my perfect language. Unfortunately Larry's doing too much re-invention with Perl 6, so instead of simply adding 'proper' O-O to perl5 we have effectively a new language. Who will move into this space (parser language that scales to application space)? So far it looks like ruby to me, fuelled by rails, but the language *must* fix overloading and allow curlys just like we learned in kindergarten (even SVR4 vi will parentheses match ON %).
Python, to me, is a fan-boy language which is already ghetto-ised.
But hey, that's just me. al.
allan at eh42 dot com

Languages never completely die. They may lose the press they once had, but legacy systems always exist. Case in point, MI-6 still uses NeXTStep, even though it's been EOLed since the early 90s.

Here is a nice pattern for multiple blocks being handed to a function. It effectively mirrors Java's anonymous inner class trick but uses a helper method to generate it. See below for a canned example

(excuse the dots in the formatting)

def multi_yield(&block)
...Class.new do |klass|
......klass.class_eval &block
...end.new
end

def mouse(&block)
...handler = multi_yield &block
...handler.moved(2)
...handler.clicked(2)
end

mouse do
...def moved(x)
......puts "moved " + x.to_s
...end
...def clicked(y)
......puts "clicked " + y.to_s
...end
end

The mutli yield helper creates an anoymous class and then yields to the user written block to fill in the methods. Things like mouse handlers always have a number of methods. Obviously in real life you would store the handler and execute the methods later upon a mouse event.

An obvious extension is to provide a default super class or a method_missing handler so that the user would not have to fill out all handlers.