Making immutable instances

[Mike Meyer]

"Giovanni Bajo" <noway at sorry.com> writes:
> Mike Meyer wrote:
>> And I have no problems with that. If you believe your class should
>> throw an error if someone calls an instances pop() method when it's
>> empty, do so.
>> Likewise, if you want to make it so a client can't change your
>> attributes, feel free to do so.
>> However, when you prevent a client from adding an attribute, you're
>> not merely making your objects immutable, you're making them
>> static. Python isn't a static language, it's a dynamic language. I
>> consider parts of it that are static to be warts.
> I always thought that adding an attribute was just as bad as changing the
> attributes, for an immutable object. But I now see your point (eventually!),
> they are pretty different issues.
>
> But, whatever attribute you add to the instance, it should *also* be immutable
> (so that, in other words, wouldn't be so different than carrying around a tuple
> with the original instance and the added attribute). This said, I think I
> devise that a language support for enforcing immutability could allow adding
> attributes to instance -- as long as those attributes then become immutable as
> well.

That's cool, but only because immutability is such a slippery concept
in Python. We both agree that tuplee are immutable, right? So consider
this:

>>> x = f()
>>> type(x)
<type 'tuple'>
>>> id(x)
136810980
>>> y = copy.deepcopy(x)
>>> y is x
False
>>> y == x
True
>>> f2(x)
>>> id(x)
136810980
>>> y == x
False
>>> 

So I'm perfectly willing to let your class declare that my attributes
be immutable, just so long as you mean the same thing by that as you
mean when you refer to tuples as immutable.

>>>> 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 :)
>> Well, that would explain why you think it's so important - it's where
>> you first encountered it.
> Yes. But I'm familiar with different object semantics, and I found the
> immutable objects to be a pretty good replacement of value semantics, and to
> implement a kind-of pass-by-value convention in a language which only has
> references.

Like I said, I don't have a problem with immutable objects per
se. It's taking away my ability to extend the objects in all the ways
that Python allows that bothers me.

Personally, I haven't found much use for immutable *objects*, as for
immutable *attributes*. Python allows the latter. In Python, you
create an immutable object by creating an object with no mutable
attributes.

>> I'd argue that it's no more important than
>> identity - which is what I was searching for when I talked about
>> interned strings sharing small integers. There are builtin types that
>> preserve identity for equal instances, at least under some
>> conditions. There are no constructs for helping you do that with
>> user-defined objects. Should we add them for the sake of
>> orthogonality? I don't think so - not without a good use case.
>
> I don't think identity is important for immutable objects (as I wrote
> elsewhere), so I don't think adding language constucts for this would prove
> useful. Instead, immutable objects *are* common, and we still miss a way to
> mark them as such.

I think identity is important from an implementation point of
view. Implementation is important - so having constructs that let
you deal with this is useful. Python has those constructs.

What Python doesn't have in general is the ability to "mark"
objects. You have the ability to create attributes that are
immutable. You can create immutable objects by creating objects which
have no mutable attributes. What more do you need?

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.