The future of Python immutability

[Daniel Fetchinson]

>> > Is the difference because of mutability versus immutability, or
>> > because of C code in Numpy versus Matlab code? Are you comparing
>> > bananas and pears?
>>
>> It consisted of something like this
>
>
> Your code does a lot of unnecessary work if you're just trying to
> demonstrate immutability is faster or slower than mutability. A simple
> test that just adds one to each element would have much less overhead.
>
> In any case, there's no doubt that immutable objects require extra time
> to create compared to re-using an existing mutable object, and that time
> is probably O(N) (until you approach the limits of available contiguous
> memory, in which case you could see O(N**2) or worse behaviour). But an
> order of magnitude difference?
>
>
>> I wasn't comparing bananas against pears. Mathworks informed me they
>> were using my code to investigate why Matlab was showing such slow-
>> downs. I am not sure what they found out, eventially. I have also
>> wondered if immutability vs. mutability was the reason, as NumPy
>> generates temporary arrays. But I have not found a better explanation
>> either. Anyhow, ~30 seconds for Matlab vs. ~3 seconds for Python is a
>> major difference.
>
> 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 ......

>, 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?

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown