[Python-ideas] Wild idea about mutability

[Sven R. Kunze]

On 06.06.2016 16:40, Steven D'Aprano wrote:
> Python classes have supported "cooperative immutability" for 20+ years.
> For example, the pure Python Decimal and Fraction classes are immutable
> only by convention, if you modify the _private attributes you can change
> them. And yet they work fine.

Nobody says it does not work fine. But sometimes, people need an 
immutability class blueprint. I saw several implementation attempts for 
such immutable-appearing objects. They tend to be hard to maintain.

>
> I'm not saying that "real immutability" wouldn't be nice to have, but I
> think that describing it as huge benefit is possible overstating it.

Since Python became a Turing-complete language, most PEPs are just that: 
preventing the re-invention of the wheel. And that's always a huge 
benefit; especially viewed economically.

>> Thinking this further, __init__ would be the only function to change the
>> state of an immutable object. Once created, it will never change.
> How would you enforce that?

That's an implementation detail.

>
>
>> Immutable also implies hashability IMHO.
> That's incorrect. We all agree that tuples are immutable, I trust.
>
> py> t = (1, 2, {}, 3)
> py> hash(t)
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> TypeError: unhashable type: 'dict'
>
>
> Immutable collections are only hashable if all their components are
> hashable.

So what? I don't see your point in quoting current behavior. Especially, 
because this is a theoretical discussion about a hypothetical behavior 
which might differ from the current one.

Furthermore, it depends on how you define what a tuple is. Is it the 
mere container to n (possibly mutable) objects? Or does it also comprise 
its components?

In the former case, it's the current behavior IIRC. In the later case, 
its components need to be immutable as well. That's basically what I was 
trying to say below.

>
>> Moreover, immutable object
>> would not be allowed to query data from global/external variables as
>> those can change and would change the observable state of the object
>> without the object noticing.
> How would you enforce that?

Don't give access to them in the first place. That again seems to me 
like another implementation detail.

>> So, the allowed way of creating a state for
>> an immutable object would be using a new container as you did (by
>> defining self._cache) and store immutable objects only there. Would this
>> make sense?
> I don't understand this paragraph, sorry.

(this might be because you split it up into several pieces? ;) )

I might refer here to your tuple example above. The tuple itself might 
look immutable but its components are not.

What immutability means instead for a domain-specific object is that it 
needs to look and to feel immutable. Usually, ones does not inspect such 
objects but use it via its public API. So, the output of its API 
definitely needs to be constant through out the life-time of the object.

Internally, the object could need to store more than a single number to 
represent its state. Maybe, even a container of containers could be 
necessary. But then all those containers and the containers' contents 
need to be immutable as well to assist the designer of the object's class.


That's at least the way I understand it how immutability would need to 
work in order to prevent errors and simplify developers' lives.


Sven