Making immutable instances

[bonono at gmail.com]

Mike Meyer wrote:
> That's not a use case, that's a debugging aid. The same logic applies
> to adding type declarations, private/public/etc. declerations, and
> similar B&D language features. It's generally considered that it's not
> a good enough reason for adding those, so it doesn't really constitute
> a good enough reason for making an instance immutable.
>
By design, this is a "don't use" feature so it would be very hard to
find a "use case" ;-)

I can only think of a situation which may not be able to detect by
testing. Say I have a module version 1 which is used by app version 1.

In your app, you attach your own attribute to an instance of the
module. Everything is fine. Now module becomes version 2 which happens
to use the same attribute name that you hang on it and the program
starts to behave strangely because they are stepping on each other's
foot without knowing it. If everything is done by the same group of
people with good communication, it may be possible to detect it. But if
the module is done by a third party, and the app is done by yet another
third party. The situation becomes complicated. Say if under debian, I
do an apt-get python-sqlobject which may be used by multiple apps. If
one of them happens to do it this way, this senario may happen.