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

[Rustom Mody]

On Sunday, June 21, 2015 at 8:03:18 AM UTC+5:30, Chris Angelico wrote:
> On Sun, Jun 21, 2015 at 11:59 AM, Rustom Mody wrote:
> > Recent thread on python ideas
> > https://mail.python.org/pipermail/python-ideas/2015-June/034177.html
> >
> > Since "python's immutable" ≠ "really immutable", we now need a "really immutable"
> 
> That's because it requires mutable memory to keep track of reference
> counts. In a non-refcountinig Python, strings and integers can be
> truly immutable; that thread is suggesting (among other options)
> simply storing the refcounts in a separate table. Conceptually, a
> string or integer IS immutable, but CPython currently needs to be able
> to fiddle with some bookkeeping data about them, in order to pretend
> it has plenty of memory. A Python implementation could theoretically
> just abandon its strings whenever it's done with them, wasting gobs of
> memory in the process, and having them in read-only memory. More
> practically, a pure mark-and-sweep GC (such as MicroPython uses)
> trades prompt disposal for simple management, and in doing so,
> achieves (I think) the same total immutability.
> 
> You have to distinguish between Python (the language) and CPython (the
> implementation) here. Python's notion of mutability has nothing to do
> with thread safety. You could achieve perfect thread safety for
> immutables by simply replicating them into every thread; it'd be
> inefficient, but perfectly legal.
> 
> ChrisA

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?

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