Lawful != Mutable (was Can Python function return multiple data?)

[Laura Creighton]

In a message of Sat, 20 Jun 2015 19:50:21 -0700, Rustom Mody writes:
>Here is Eric Snow:
>
>| Keep in mind that by "immutability" I'm talking about *really*
>| immutable, perhaps going so far as treating the full memory space
>| associated with an object as frozen.  For instance, we'd have to
>| ensure that "immutable" Python objects like strings, ints, and tuples
>| do not change (i.e. via the C API).  The contents of involved
>| tuples/containers would have to be likewise immutable.  Even changing
>| refcounts could be too much, hence the idea of moving refcounts out to
>| a separate table.
>|  
>| This level of immutability would be something new to Python.  We'll
>| see if it's necessary.  If it isn't too much work it might be a good
>| idea regardless of the multi-core proposal.
>
>Does the second para look like CPython implementation or python-the-language?

Regardless of how it looks, it's only about the CPython implementation.
PyPy and Jython will not have this problem, as they don't have a C API
to worry about.  Of course the PyPy position is that STM will solve
all of this in a much cleaner way, and we're getting closer to a
perfectly working solution for as many cores as you have (as opposed
to only 4) that works on all OS's (as opposed to just 64 bit linux)
all the time.

This is very much a 'how to hack CPython to support multiple cores'
idea.  It's a 'kill the GIL' proposal.  But PyPy-STM and Jython
don't have a GIL, so they don't need to kill it.

>Also note the 'Even' in the first para. ie Eric is talking of low-level
>(ie thread-safety, refcounting etc) immutability after the even and higher
>level semantic immutability before

The ref-counting should be a very strong hint that this is a CPython
implementation proposal.  Again, Jython and PyPy don't use a ref counting
GC.

Laura