Making immutable instances

[Giovanni Bajo]

Mike Meyer wrote:

>>> Note that this property of __slots__ is an implementation detail.
>>> You
>>> can't rely on it working in the future.
>> I don't "rely" on it. I just want to catch bugs in my code.
>
> I certainly hope you're not relying on it to catch bugs. You should do
> proper testing instead. Not only will that catch pretty much all the
> bugs you mention later - thus resolving you of the need to handcuff
> clients of your class - it will catch lots of other bugs as well.

This sounds a little academic. Writing a real Python program without testing is
impossible or close to it, so you are really not telling me anything new. Even
*with* testing, there are bugs. I'm sure you well know this.

My feeling is that you're trying to get too much out of my words. I'm not
trying to handcuff anyone. You seem to concentrate on me trying to avoid people
adding attributes to my precious objects. It's not that. If I write a class and
want it to be immutable, it is because it has to be so. If I write a queue
class and I say that people shouldn't call pop() if it's empty, I mean it. If I
enforce it with a RuntimeError, I'm not thinking I'm handcuffing someone. I
don't see a ImmutableError to be so different from it.

I often design objects that I want to be immutable. I might keep it as a key in
dictionaries, or I might have external, non-intrusive caches of some kind
relying on the fact that the instance does not change. Of course, it *might* be
that testing uncovers the problem. Unittests tend to be pretty specific, so in
my experience they happen to miss *new* bugs created or uncovered by the
integration of components. Or if they hit it, you still have to go through
debug sessions. An ImmutableError would spot the error early.

In my view, enforcing immutability is no different from other forms of
self-checks. Do you reckon all kind of asserts are useless then? Surely they
don't help for anything that a good unittest couldn't uncover. But they help
catching bugs such as breakage of invariants immediately as they happen.
Immutability can be such an invariant.


>>>> If it's not a wart, why would it be a wart for user-defined types
>>>> to
>>>> have the same behaviour?
>>>
>>> It's a wart because user-defined classes *don't* have the same
>>> behavior.
>> Then *my* solution for this would be to give user-defined classes a
>> way to behave like builtins, eg. explicitally and fully implement
>> immutability.
>
> Well, if you want to propose a change to the language, you need a good
> use case to demonstrate the benefits of such a change. Do you have
> such a use case? Catching bugs doesn't qualify, otherwise Python would
> be radically different from what it is.


One good reason, in my opinion, is that there *are* immutable objects in
Python, among builtins. And people can easily build extension objects which are
immutable. So being impossible to write a regular object in Python which is
immutable is not orthogonal to me.

Now let me ask you a question. What is a good use case for "assert" that
justifies its introduction in the language? What is a good usecase for module
'unittest' which justifies its introduction in the standard library? Why do you
think tuples are immutable and *enforced* to be so?


>> Immutability is an important concept in Python programs, and I'm
>> impressed it does not have explicit support.
>
> I'm not convinced that immutability is that important a concept. Yeah,
> you have to know about it, but it seems more like an implementation
> detail than a crucial concept.

Probably it's just a matter of design styles.

> I'm not sure it's more important than
> things like interned strings and the sharing of small integers.  Most
> of the discussion of immutables here seems to be caused by newcomers
> wanting to copy an idiom from another language which doesn't have
> immutable variables. Their real problem is usually with binding, not
> immutability.

I'm not such a newcomer, but (how funny) Python is *the* language that
introduced me to the concept of immutable objects and their importance in
design :)
-- 
Giovanni Bajo