Immutability and Python

[andrea crotti]

I have a philosofical doubt about immutability, that arised while doing
the SCALA functional programming course.

Now suppose I have a simple NumWrapper class, that very stupidly does:

class NumWrapper(object):
def __init__(self, number):
self.number = number

and we want to change its state incrementing the number, normally I
would do this

def increment(self):
self.number += 1


But the immutability purists would instead suggest to do this:

def increment(self):
return NumWrapper(self.number + 1)


Now on one hand I would love to use only immutable data in my code, but
on the other hand I wonder if it makes so much sense in Python.

My impression is that things get more clumsy in the immutable form, for
example in the mutable form I would do simply this:

number = NumWrapper(1)
number.increment()

while with immutability I have to do this instead:
new_number = number.increment()

But more importantly normally classes are way more complicated than my
stupid example, so recreating a new object with the modified state might
be quite complex.

Any comments about this? What do you prefer and why?

 

[Paul Rubin]

and we want to change its state incrementing the number ...
the immutability purists would instead suggest to do this:
def increment(self):
return NumWrapper(self.number + 1)

Immutability purists would say that numbers don't have "state" and if
you're trying to change a number's state by incrementing it, that's not
immutability. You end up with a rather different programming style than
imperative programming, for example using tail recursion (maybe wrapped
in an itertools-like higher-order function) instead of indexed loops to
iterate over a structure.

 

[Chris Angelico]

Immutability purists would say that numbers don't have "state" and if
you're trying to change a number's state by incrementing it, that's not
immutability. You end up with a rather different programming style than
imperative programming, for example using tail recursion (maybe wrapped
in an itertools-like higher-order function) instead of indexed loops to
iterate over a structure.

In that case, rename increment to next_integer and TYAOOYDAO. [1]
You're not changing the state of this number, you're locating the
number which has a particular relationship to this one (in the same
way that GUI systems generally let you locate the next and previous
siblings of any given object).

ChrisA
[1] "there you are, out of your difficulty at once" - cf WS Gilbert's "Iolanthe"

 

[andrea crotti]

Immutability purists would say that numbers don't have "state" and if
you're trying to change a number's state by incrementing it, that's not
immutability. You end up with a rather different programming style than
imperative programming, for example using tail recursion (maybe wrapped
in an itertools-like higher-order function) instead of indexed loops to
iterate over a structure.

In that case, rename increment to next_integer and TYAOOYDAO. [1]
You're not changing the state of this number, you're locating the
number which has a particular relationship to this one (in the same
way that GUI systems generally let you locate the next and previous
siblings of any given object).

ChrisA
[1] "there you are, out of your difficulty at once" - cf WS Gilbert's "Iolanthe"

Yes the name should be changed, but the point is that they are both
ways to implement the same thing.

For example suppose I want to have 10 objects (for some silly reason)
that represent the next number, in the first case I would do:

numbers = [NumWrapper(orig.number)] * 10
for num in numbers:
num.increment()

while in the second is as simple as:
numbers = [orig.next_number()] * 10

composing things become much easier, but as a downside it's not always
so easy and convienient to write code in this way, it probably depends
on the use case..

 

[Steven D'Aprano]

I have a philosofical doubt about immutability, that arised while doing
the SCALA functional programming course.

"Philosophical". Like most words derived from the ancient Greeks, the "F"
sound uses "ph" rather than "f".

Now suppose I have a simple NumWrapper class, that very stupidly does:

class NumWrapper(object):
def __init__(self, number):
self.number = number

and we want to change its state incrementing the number, normally I
would do this

def increment(self):
self.number += 1

That's a perfectly fine (although incomplete) design for a mutable
numeric class. But as the basis of an immutable class, it's lousy.

But the immutability purists would instead suggest to do this:

def increment(self):
return NumWrapper(self.number + 1)

Only if they don't know Python very well

In this example, the right way to get an immutable class is:

class NumWrapper(int): # not exactly a *wrapper*
def increment(self):
return self.__class__(self + 1)


and you're done. Immutability for free, because you don't store state
anywhere that pure-Python code can get to it. (Technically, using ctypes
you could mutate it, so don't do that.)

Here's a sketch of another technique:

class MyNum(object):
__slots__ = '_num'
def __new__(cls, arg):
instance = object.__new__(cls)
instance._num = int(arg)
return instance
@property
def value(self):
return self._num
def increment(self):
return self.__class__(self.value + 1)

Now on one hand I would love to use only immutable data in my code, but
on the other hand I wonder if it makes so much sense in Python.

You can go a long, long way using only immutable primitives and
functional style in Python, and I recommend it.

On the other hand, a *purely* functional approach doesn't make a lot of
sense for some tasks. Python is not a pure functional language, and
doesn't force you to hammer round pegs into the square hole of the
functional style.

Some problems are best modelled by an object that holds state and can
change over time, e.g. a database or a dict. Other problems are best
modelled by constants which do not change, but can be replaced by other
constants, e.g. numbers. Some problems fall into a grey area, e.g. lists,
arrays, sets, sequences, strings.

My advice is to always be alert for square pegs in your code, and write
them in functional style using immutable instances, but don't be a
purist. If you have a round peg, write that part of your code using a
mutable instance with in-place mutator methods, and be happy.

The beauty of Python is that you can use whichever style suits the
problem best.

My impression is that things get more clumsy in the immutable form, for
example in the mutable form I would do simply this:

number = NumWrapper(1)
number.increment()

while with immutability I have to do this instead:
new_number = number.increment()

Why is this clumsy? Do you have problems with this?

x = 1
y = x+1

 

[rusi]

Any comments about this? What do you prefer and why?

Im not sure how what the 'prefer' is about -- your specific num
wrapper or is it about the general question of choosing mutable or
immutable types?

If the latter I would suggest you read
http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP

[And remember that Stepanov is the author of C++ STL, he is arguably
as important in the C++ world as Stroustrup]

 

[Neal Becker]

Any comments about this? What do you prefer and why?

Im not sure how what the 'prefer' is about -- your specific num
wrapper or is it about the general question of choosing mutable or
immutable types?

If the latter I would suggest you read
http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP

[And remember that Stepanov is the author of C++ STL, he is arguably
as important in the C++ world as Stroustrup]

The usual calls for immutability are not related to OO. They have to do with
optimization, and specifically with parallel processing.

 

[rusi]

Im not sure how what the 'prefer' is about -- your specific num
wrapper or is it about the general question of choosing mutable or
immutable types?

If the latter I would suggest you read
http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP

[And remember that Stepanov is the author of C++ STL, he is arguably
as important in the C++ world as Stroustrup]

The usual calls for immutability are not related to OO.  They have to do with
optimization, and specifically with parallel processing.

From the time of Backus' Turing award
http://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf
it is standard fare that
assignment = imperative programming (which he collectively and
polemically called the von Neumann bottleneck)
That what he decried as 'conventional programming languages' today
applies to OO languages; see
http://www.cs.tufts.edu/~nr/backus-lecture.html

A more modern viewpoint:

--------------
Object-oriented programming is eliminated entirely from the
introductory curriculum, because it is both anti-modular and anti-
parallel by its very nature, and hence unsuitable for a modern CS
curriculum. A proposed new course on object-oriented design
methodology will be offered at the sophomore level for those students
who wish to study this topic.

 

[Thomas Rachel]

Am 29.10.2012 16:20 schrieb andrea crotti:

Now on one hand I would love to use only immutable data in my code, but
on the other hand I wonder if it makes so much sense in Python.

You can have both. Many mutable types distinguish between them with
their operators.

To pick up your example,


class NumWrapper(object):
def __init__(self, number):
self.number = number
def __iadd__(self, x):
self.number += x
return self
def __add__(self, x):
return NumWrapper(self.number + x)

So with

number += 1

you keep the same object and modify it, while with

number = number + 1

or

new_number = number + 1

you create a new object.

But more importantly normally classes are way more complicated than my
stupid example, so recreating a new object with the modified state might
be quite complex.

Any comments about this? What do you prefer and why?

That's why I generally prefer mutable objects, but it can depend.


Thomas