PEP 218 Re: ANN: set-0.1 module available

[Fernando Pérez]

Kragen Sitaker wrote:

>> by not forcing the performance penalty. Simply because it makes the
>> language more scalable and worry-free.
> 
> Immutable objects need to be copied to effect small changes; mutable
> objects can't be safely shared between code written by people who
> don't communicate, and must therefore be copied at every library
> boundary.  Which one is a larger performance penalty depends on your
> application.  Most applications benefit from a mixture of some mutable
> and some immutable objects, although as jb points out, the semantics
> of immutable objects can be implemented efficiently with
> behind-the-scenes mutation at the cost of some compiler complexity.
> 
> Mutability tends toward surprising interactions and aliasing bugs, of
> course.  Saying it makes the language more "worry-free" is the
> farthest thing from the truth.

Good point. It makes it 'worry-free' in the direction of performance scaling 
when you can deal with the in-place issues (the kind of issues I'm used to 
dealing with in scientific computing) at the cost of introducing worries in 
terms of potentially subtle bugs. A great example of the contrast is the 
difference in slicing behavior of python lists (a copy operation) versus 
numeric arrays (an in-place reference). For me, numeric arrays behave the way 
I want them (fast) but I'm always aware of not stepping on the mine which 
in-place referencing can be: it buys me speed, but I must be careful.

As always, it's a tradeoff. When I said worry-free I was only considering my 
perspective: scientific computing where performance matters a lot. I'm 
already so happy to have python's forgiveness and easiness that I don't mind 
a few places where care must be exterted. It's already allowing me to forgo 
raw C for many things! But you are right in pointing a different direction 
for the problem.

Cheers,

f.