PEP 218 Re: ANN: set-0.1 module available

[Kragen Sitaker]

Fernando Pérez <fperez528 at yahoo.com> writes:
> So I know perfectly well that immutable objects can simulate in-place 
> operations. The question is whether the performance hit you take is 
> significant or not. Since it _can_ be (try a large loop on a string with += 
> and watch your machine hit a wall), I tend to be of the opinion that unless 
> there's a compelling reason to make the objects immutable, one is better off 
> 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.