The future of Python immutability

[Steven D'Aprano]

On Tue, 08 Sep 2009 11:23:05 -0700, Daniel Fetchinson wrote:

>> How does Matlab speed compare to Python in general? Ruby, for example,
>> is an order of magnitude slower than Python (at least it was last time
>> I looked)
> 
> For what operations? Under what circumstances? I'm just being pedantic
> because you mentioned comparing bananas and pears ......

In general, Ruby was significantly slower than Python "most of the time", 
although my recollection was wrong about it being an order of magnitude 
difference -- it was more like a factor of 3-6 depending on the specific 
benchmark being tested. This was for Ruby 1.8, Ruby 1.9 included some 
significant speedups, including tail-optimization which makes it about 
three times as fast as Python 2.5 for tail-recursive functions.

Of course there's a lot of hand-waving in the above. Language 
implementations vary in their performance for specific pieces of code -- 
it's invalid to conclude that every single Ruby script will be exactly 3 
times faster than every single Python script. But one can argue that Ruby 
1.8 was, in general, at least three times slower than Python 2.5 
comparing equivalent pieces of code.

There's nothing controversial or strange over the claim that a well-
written (but not heavily optimized) C program will be much faster than 
the equivalent Python program, which in turn will be faster than the 
equivalent PHP program. Nobody is surprised to learn that Numpy's C 
implementation of some function will almost certainly out-perform the 
same function written in pure Python. It's easy to oversell the idea that 
"language X is faster than language Y", but that's not what I'm doing. 
I'm asking, all else being equal, how does the speed of Matlab compare to 
the speed of Numpy?


 
>>, not because of immutable arrays, but just because of the speed
>> of the language.
> 
> Ummmm, what is 'speed of a language'? I thought ruby or python or
> anything else as a language is separate from their implementations.
> Implementations might have 'speed' but languages don't. Aren't you
> comparing bananas and pears again?

Go point -- of course you're right, and I was sloppy. I meant "the speed 
of the specific implementation".



-- 
Steven