Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > The future of Python immutability

Reply
Thread Tools

The future of Python immutability

 
 
John Nagle
Guest
Posts: n/a
 
      09-03-2009
Python's concept of immutability is useful, but it could be more
general.

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.

Python doesn't have immutable objects as a general concept, but
it may be headed in that direction. There was some fooling around
with an "immmutability API" associated with NumPy back in 2007, but
that was removed. As more immutable types are added, a more general
approach may be useful.

Suppose, for discussion purposes, we had general "immutable objects".
Objects inherited from "immutableobject" instead of "object" would be
unchangeable once "__init__" had returned. Where does this take us?

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.

Java "synchronized" turned out to be a headache partly because trying to
figure out how to lock all the "little stuff" being passed around
a headache. But Java doesn't have immutable objects. Python does,
and that can be exploited to make thread-based programming cleaner.

The general idea is that synchronized objects would have built in
locks which would lock at entry to any function of the object and
unlock at exit. The lock would also unlock at explicit waits. A
"Queue" object would be a good example of a synchronized object.

With this mechanism, multi-thread programs with shared data
structures can be written with little or no explicit locking by
the programmer. If the restrictions are made a bit stricter,
strict enough that threads cannot share mutable unsynchronized data,
removal of the "global interpreter lock" is potentially possible.
This is a route to improved performance on modern multi-core CPUs.

John Nagle

 
Reply With Quote
 
 
 
 
Nigel Rantor
Guest
Posts: n/a
 
      09-03-2009

John Nagle wrote:
> Python's concept of immutability is useful, but it could be more
> general.
>
> 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.
>
> Python doesn't have immutable objects as a general concept, but
> it may be headed in that direction. There was some fooling around
> with an "immmutability API" associated with NumPy back in 2007, but
> that was removed. As more immutable types are added, a more general
> approach may be useful.
>
> Suppose, for discussion purposes, we had general "immutable objects".
> Objects inherited from "immutableobject" instead of "object" would be
> unchangeable once "__init__" had returned. Where does this take us?
>
> 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.


Yes, this is one of the reasons I am currently learning Haskell, I am
not yet anywhwere near proficient but the reason I am looking into FP is
because of some of the claims of the FP community, particularly Erlang,
regarding the benefits of pure FP with respect to multi-threading.

It's a shame this post came right now since I'm not really up-to-speed
enough with Haskell to comment on it with repsect to multi-threading.

<context>
I program Perl, Java and C++ for my day job, I've spent a lot of time
making multithreaded programs work correctly and have even experienced
the POE on a large project. So my comments below are based on experience
of these languages.
</context>

> Such programs are free of most race conditions, without much
> programmer effort to make them so.


I disagree. They are not free of most race conditions, and it still
takes a lot of effort. Where did you get this idea from? Have you been
reading some Java primer that attempts to make it sound easy?

> Java "synchronized" turned out to be a headache partly because
> trying to
> figure out how to lock all the "little stuff" being passed around
> a headache. But Java doesn't have immutable objects. Python does,
> and that can be exploited to make thread-based programming cleaner.


This is nothing to do with Java, any multithreaded language that has
mutable shared state has exactly the same problems. Can we talk about
threading rather than Java please? Additionally Java provides a lot more
than monitors (synchronized) for controlling multiple threads.

Java does have immutable objects. Strings in Java are immutable for
example. As are the object-based numeric types, Bytes, Characters etc.

There are lots and lots of immutable types in Java and you can make your
own by creating a class with no mutator methods and declaring it "final".

> The general idea is that synchronized objects would have built in
> locks which would lock at entry to any function of the object and
> unlock at exit. The lock would also unlock at explicit waits. A
> "Queue" object would be a good example of a synchronized object.
>
> With this mechanism, multi-thread programs with shared data
> structures can be written with little or no explicit locking by
> the programmer. If the restrictions are made a bit stricter,
> strict enough that threads cannot share mutable unsynchronized data,
> removal of the "global interpreter lock" is potentially possible.
> This is a route to improved performance on modern multi-core CPUs.


Right, this is where I would love to have had more experience with Haksell.

Yes, as soon as you get to a situation where no thread can access shared
state that is mutable your problems go away, you're also getting no work
done becasue the threads, whilst they may be performing lots of
interesting calculations have no way of allowing the rest of the
program, or operating system, know about it.

You can, today, in any language that provides threads, make any number
of threaded programs that do not contain any race conditions, it's just
that most of them are terribly dull and uninteresting.

I'd love for someone from the Haskell/Erlang/<other> pure FP community
provide some canonical example of how this is acheived in pure FP. I'll
get there soon but I'm not going to skip ahead in my reading, I'm still
trying to learn the basics.

So, in response to your point of trying to get an immutable API so that
Python can easily have multi-threaded programs that do not present race
conditions I would say the following:

That is not the challenge, that's the easy part. The challenge is
getting useful information out of a system that has only been fed
immutable objects.

Regards,

Nigel
 
Reply With Quote
 
 
 
 
Stefan Behnel
Guest
Posts: n/a
 
      09-03-2009
Nigel Rantor wrote:
>
> John Nagle wrote:
>> 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.

>
> I disagree. They are not free of most race conditions, and it still
> takes a lot of effort. Where did you get this idea from? Have you been
> reading some Java primer that attempts to make it sound easy?


Read again what he wrote. In a language with only immutable data types
(which doesn't mean that you can't efficiently create modified versions of
a data container), avoiding race conditions is trivial. The most well known
example is clearly Erlang. Adding "synchronised" data structures to that
will not make writing race conditions much easier.

Stefan
 
Reply With Quote
 
Nigel Rantor
Guest
Posts: n/a
 
      09-03-2009
Stefan Behnel wrote:
> Nigel Rantor wrote:
>> John Nagle wrote:
>>> 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.

>> I disagree. They are not free of most race conditions, and it still
>> takes a lot of effort. Where did you get this idea from? Have you been
>> reading some Java primer that attempts to make it sound easy?

>
> Read again what he wrote. In a language with only immutable data types
> (which doesn't mean that you can't efficiently create modified versions of
> a data container), avoiding race conditions is trivial. The most well known
> example is clearly Erlang. Adding "synchronised" data structures to that
> will not make writing race conditions much easier.


My comment you quoted was talking about Java and the use of
synchronized. I fthat was unclear I apologise.

Please feel free to read the entirety of my post before replying.

n
 
Reply With Quote
 
Stefan Behnel
Guest
Posts: n/a
 
      09-03-2009
Nigel Rantor wrote:
> My comment you quoted was talking about Java and the use of
> synchronized. I fthat was unclear I apologise.


Well, it was clear. But it was also unrelated to what the OP wrote. He was
talking about the semantics of "synchronized" in Java, not the use.

Stefan
 
Reply With Quote
 
Stefan Behnel
Guest
Posts: n/a
 
      09-03-2009
John Nagle wrote:
> With this mechanism, multi-thread programs with shared data
> structures can be written with little or no explicit locking by
> the programmer. If the restrictions are made a bit stricter,
> strict enough that threads cannot share mutable unsynchronized data,
> removal of the "global interpreter lock" is potentially possible.
> This is a route to improved performance on modern multi-core CPUs.


The main problem with this is that the existing data structures are, well,
there. You can't replace them without breaking all existing Python code,
i.e. without basically inventing a new language. If that's required for
removing the GIL, I doubt that it will ever be done.

Stefan
 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      09-03-2009
Stefan Behnel <(E-Mail Removed)> writes:
> Read again what he wrote. In a language with only immutable data types
> (which doesn't mean that you can't efficiently create modified versions of
> a data container), avoiding race conditions is trivial. The most well known
> example is clearly Erlang. Adding "synchronised" data structures to that
> will not make writing race conditions much easier.


Nonetheless, Erlang is subject to all kinds of traditional threading
problems such as deadlocks. Haskell's use of software transactional
memory may(?) avoid some of the problems but at a performance cost.
 
Reply With Quote
 
Gabriel Genellina
Guest
Posts: n/a
 
      09-03-2009
En Thu, 03 Sep 2009 15:03:13 -0300, John Nagle <(E-Mail Removed)>
escribió:

> Python's concept of immutability is useful, but it could be more
> general.
>
> 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.


In the current CPython implementation, every object has a reference count,
even immutable ones. This must be a writable field - and here you have
your race condition, even for immutable objects.

--
Gabriel Genellina

 
Reply With Quote
 
John Nagle
Guest
Posts: n/a
 
      09-04-2009
Gabriel Genellina wrote:
> En Thu, 03 Sep 2009 15:03:13 -0300, John Nagle <(E-Mail Removed)>
> escribió:
>
>> Python's concept of immutability is useful, but it could be more
>> general.
>>
>> 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.

>
> In the current CPython implementation, every object has a reference
> count, even immutable ones. This must be a writable field - and here you
> have your race condition, even for immutable objects.


That's an implementation problem with CPython. I'm looking at this as
a language design issue. Shed Skin, which is garbage-collected, doesn't
have that problem. Look ahead to a new generation of Python implementations
that go fast and use multiprocessors effectively.

John Nagle
 
Reply With Quote
 
r
Guest
Posts: n/a
 
      09-04-2009
"""The future of Python immutability"""

Define future:
The future is a time period commonly understood to contain all
events that have yet to occur. It is the opposite of the past, and is
the time after the present

Define immutability:
Not subject or susceptible to change. In object-oriented and
functional programming, an immutable object is an object whose state
cannot be modified after it is created. This is in contrast to a
mutable object, which can be modified after it is created.



hmm, applying this logic i'd have to say about the same really.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Immutability and Python andrea crotti Python 8 11-08-2012 07:38 AM
Re: Immutability and Python andrea crotti Python 0 10-29-2012 03:44 PM
Python String Immutability Broken! Roy Smith Python 2 08-25-2008 02:41 AM
Easy immutability in python? Terry Hancock Python 3 03-04-2006 08:17 PM
Re: Easy immutability in python? Terry Hancock Python 2 03-04-2006 08:17 PM



Advertisments