Immutability and Python

Discussion in 'Python' started by andrea crotti, Oct 29, 2012.

  1. 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?
     
    andrea crotti, Oct 29, 2012
    #1
    1. Advertising

  2. andrea crotti

    Paul Rubin Guest

    andrea crotti <> writes:
    > 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.
     
    Paul Rubin, Oct 29, 2012
    #2
    1. Advertising

  3. On Tue, Oct 30, 2012 at 2:55 AM, Paul Rubin <> wrote:
    > andrea crotti <> writes:
    >> 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.


    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"
     
    Chris Angelico, Oct 29, 2012
    #3
  4. 2012/10/29 Chris Angelico <>:
    > On Tue, Oct 30, 2012 at 2:55 AM, Paul Rubin <> wrote:
    >> andrea crotti <> writes:
    >>> 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.

    >
    > 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"
    > --
    > http://mail.python.org/mailman/listinfo/python-list



    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..
     
    andrea crotti, Oct 29, 2012
    #4
  5. On Mon, 29 Oct 2012 15:20:02 +0000, andrea crotti wrote:

    > 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



    --
    Steven
     
    Steven D'Aprano, Oct 29, 2012
    #5
  6. andrea crotti

    rusi Guest

    On Oct 29, 8:20 pm, andrea crotti <> wrote:
    <snipped>
    > 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]
     
    rusi, Oct 30, 2012
    #6
  7. andrea crotti

    Neal Becker Guest

    rusi wrote:

    > On Oct 29, 8:20 pm, andrea crotti <> wrote:
    > <snipped>
    >> 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.
     
    Neal Becker, Oct 30, 2012
    #7
  8. andrea crotti

    rusi Guest

    On Oct 31, 1:45 am, Neal Becker <> wrote:
    > rusi wrote:
    > > On Oct 29, 8:20 pm, andrea crotti <> wrote:
    > > <snipped>
    > >> 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.


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

    from http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/

    Call it polemical if you like; noting that that's Carnegie Mellon.
     
    rusi, Oct 31, 2012
    #8
  9. 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
     
    Thomas Rachel, Nov 8, 2012
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. andrea crotti

    Re: Immutability and Python

    andrea crotti, Oct 29, 2012, in forum: Python
    Replies:
    0
    Views:
    184
    andrea crotti
    Oct 29, 2012
  2. andrea crotti

    Re: Immutability and Python

    andrea crotti, Oct 29, 2012, in forum: Python
    Replies:
    0
    Views:
    179
    andrea crotti
    Oct 29, 2012
  3. Mark Lawrence

    Re: Immutability and Python

    Mark Lawrence, Oct 29, 2012, in forum: Python
    Replies:
    0
    Views:
    189
    Mark Lawrence
    Oct 29, 2012
  4. Paul Rubin

    Re: Immutability and Python

    Paul Rubin, Oct 29, 2012, in forum: Python
    Replies:
    7
    Views:
    170
    Steven D'Aprano
    Oct 29, 2012
  5. Terry Reedy

    Re: Immutability and Python

    Terry Reedy, Oct 29, 2012, in forum: Python
    Replies:
    0
    Views:
    179
    Terry Reedy
    Oct 29, 2012
Loading...

Share This Page