The future of Python immutability

[Terry Reedy]

We must have different ideas of "sizable"

Numbers, strings, and tuples are immutable...
Lists, dictionaries, and pretty much anything else (functions, class
instances, etc.) are mutable in one way or another... I'd say the
mutables are in the majority <G>

I think it depends on whether one counts classes or instances. Typical
programs have a lot of numbers and strings.

tjr

 

[Simon Brunning]

I think it depends on whether one counts classes or instances. Typical programs have a lot of numbers and strings.

Ah, but immutable instances can be, and often are, interned. This will
cut down on their number considerably. ;-)

 

[Graham Breed]

In the beginning, strings, tuples, and numbers were immutable, and
everything else was mutable. That was simple enough. But over time,
Python has acquired more immutable types - immutable sets and immutable
byte arrays. Each of these is a special case.

Immutability is interesting for threaded programs, because
immutable objects can be shared without risk. Consider a programming
model where objects shared between threads must be either immutable or
"synchronized" in the sense that Java uses the term. Such programs
are free of most race conditions, without much programmer effort to
make them so.

Of course, tuples would still be a special case because they
may contain mutable objects. You need to check they're
immutable all the way down.

Nothing to do with threading, but it's also the cause of
this weirdness:

http://bytes.com/topic/python/answers/752154-list-tuple

>>a = ([1], 2)
>>a[0] += [3]

succeeds, but raises an error.


Graham

 

[John Nagle]

Of course, tuples would still be a special case because they may contain
mutable objects. You need to check they're immutable all the way down.

Right. Tracking mutablity and ownership all the way down without
making the language either restrictive or slow is tough.

In multi-thread programs, though, somebody has to be clear on who owns
what. I'm trying to figure out a way for the language, rather than the
programmer, to do that job. It's a major source of trouble in threaded
programs.

John Nagle

 

[Paul Rubin]

Right. Tracking mutablity and ownership all the way down without
making the language either restrictive or slow is tough.

In multi-thread programs, though, somebody has to be clear on who owns
what. I'm trying to figure out a way for the language, rather than the
programmer, to do that job. It's a major source of trouble in threaded
programs.

Python's threading system is modelled after Java's, which basically
uses explicit locks under programmer control. That has its hazards
but does manage to multiprocess effectively. CPython's
multiprocessing is limited by the notorious GIL, but that's an
implementation artifact.

Having the language automatically manage ownership of mutable objects
without a fancy type system sounds self-contradictory. Erlang (which
is typeless like Python) does it by not allowing mutation at all.
Haskell uses a type-based scheme around software transactional memory
(STM) primitives:

http://book.realworldhaskell.org/read/software-transactional-memory.html

The Microsoft Research "Singularity" OS may also be of interest.

 

[Hendrik van Rooyen]

Right. Tracking mutablity and ownership all the way down without
making the language either restrictive or slow is tough.

In multi-thread programs, though, somebody has to be clear on who owns
what. I'm trying to figure out a way for the language, rather than the
programmer, to do that job. It's a major source of trouble in threaded
programs.

I think that trying to make the language instead of the programmer responsible
for this is a ball-buster. It is unlikely to be either easy or cheap.
I would rather have the programmer responsible for the mental model, and give
her the tools to do the job with.

In any case - if you do not actually like juggling with knives, then you
should not be mucking around with concurrency, and by making the language
safe, you are taking the fun out.

- Hendrik

 

[Paul Rubin]

In any case - if you do not actually like juggling with knives, then you
should not be mucking around with concurrency, and by making the language
safe, you are taking the fun out.

Oh come on, Erlang and Haskell both take care of it rather well.

 

[Steven D'Aprano]

I think that trying to make the language instead of the programmer
responsible for this is a ball-buster. It is unlikely to be either easy
or cheap. I would rather have the programmer responsible for the mental
model, and give her the tools to do the job with.

That was the situation 20 years ago with memory management. I'm sure
people back then thought that the Right Solution was to give the
programmer tools to get the job done, and hope they can avoid
dereferencing nil pointers and memory leaks and all the other cruft of
hand-managing memory. Today, we have garbage collectors and high-level
languages like Ruby, Python, Haskell etc that manage that for you, and
even heavyweight garbage collectors are practical for the majority of
userspace applications.

In any case - if you do not actually like juggling with knives, then you
should not be mucking around with concurrency, and by making the
language safe, you are taking the fun out.

If by "fun" you mean "screaming horrors", I agree.

 

[John Nagle]

That was the situation 20 years ago with memory management.

Good point.

The other big point is the CPython deals with concurrency by
preventing it. This is killing performance on multi-core CPUs.
Read "http://www.dabeaz.com/python/GIL.pdf", which demonstrates
just how awful the current GIL implementation is. Adding more
CPUs slows CPython down.

John Nagle

 

[Daniel Fetchinson]

Is the difference because of mutability versus immutability, or

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?



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

 

[Steven D'Aprano]

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?

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".