Making immutable instances

[Alex Martelli]

Re: Making immutable instances

Ben Finney <bignose+hate s-spam@benfinney. id.au> wrote:
...[color=blue][color=green]
> > A type implemented in C offers different possibilities than one
> > implemented in Python -- no deep conceptual reason, just practical
> > ones.[/color]
>
> So, in the hypothetical situation that all Python types were
> implemented in pure Python, what would the ideal behaviour for
> immutables be? Or would there be no immutables?[/color]

Pypy is implementing Python in Python and using just the same semantics
as CPython. Of course, there IS some sleight of hand, because there are
still two "sides" -- interpreter level and application level... stuff
implemented in interpreter level Python plays just the same role as
stuff implemented in C does in CPython.

Musing theoretically, I can see an *ideal* approach would have to meet
higher aesthetic goals than Python's -- reach for richer symmetry, e.g.,
all types existing in mutable and immutable flavors (Ruby comes sort of
close, with plain and frozen objects). Python's more about pragmaticity
than purity (and, therefore, than idealness)...

[color=blue]
> I'm looking for a "consenting adults" restriction: classes will have
> immutable instances only where it makes sense from the class protocol.
> I'm not going to lose sleep over users who go looking for trouble.[/color]

Yep, I understand this, now that you've explained in more detail, and
FWIW I do approve.

One more piece of advice: you might document that, in circumstances
where (using a normal Python class's instances) the obvious approach
would be to add some per-instance attribute to the instances (with
semantics totally outside the class), your users might be better advised
to employ a weakref.WeakKey Dictionary with the instances as keys.
Although a tad more cumbersome, they can get the same semantics this
way, even though it may seem "inside-out" wrt the "intuitive" approach.


Alex

[Giovanni Bajo]

Re: Making immutable instances

Mike Meyer wrote:
[color=blue][color=green][color=darkred]
>>> Note that this property of __slots__ is an implementation detail.
>>> You
>>> can't rely on it working in the future.[/color]
>> I don't "rely" on it. I just want to catch bugs in my code.[/color]
>
> 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.[/color]

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.

[color=blue][color=green][color=darkred]
>>>> 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.[/color]
>> Then *my* solution for this would be to give user-defined classes a
>> way to behave like builtins, eg. explicitally and fully implement
>> immutability.[/color]
>
> 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.[/color]


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?

[color=blue][color=green]
>> Immutability is an important concept in Python programs, and I'm
>> impressed it does not have explicit support.[/color]
>
> 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.[/color]

Probably it's just a matter of design styles.
[color=blue]
> 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.[/color]

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

[Björn Lindström]

Re: Making immutable instances

"Giovanni Bajo" <noway@sorry.co m> writes:
[color=blue]
> 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.[/color]

But why would you call it that, when the object isn't actually
implemented as immutable?

It's pretty misleading to call an object immutable rather than saying
that it shouldn't be changed for some reason.

Throw an exception that describes why it doesn't make sense to change
that particular object instead.

As I said before, I think you're confusing the (in Python pretty
non-existent) concept of encapsulation with Python's immutable types,
which are immutable because the implementation demands it. (A fact I
hope will disappear at some point.)

--
Björn Lindström <bkhl@stp.lingf il.uu.se>
Student of computational linguistics, Uppsala University, Sweden

[Paul Rubin]

Re: Making immutable instances

bkhl@stp.lingfi l.uu.se (Björn Lindström) writes:[color=blue]
> As I said before, I think you're confusing the (in Python pretty
> non-existent) concept of encapsulation with Python's immutable types,
> which are immutable because the implementation demands it. (A fact I
> hope will disappear at some point.)[/color]

What implementation demand? If Python's designers wanted mutable
strings or tuples, Python could have them. Python strings and tuples
are immutable by design, not by accident of implementation. Wanting
to make immutable class instances out of the same design
considerations is perfectly reasonable.

[Giovanni Bajo]

Re: Making immutable instances

Björn Lindström wrote:
[color=blue][color=green]
>> 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.[/color]
>
> But why would you call it that, when the object isn't actually
> implemented as immutable?[/color]

I think you misunderstood my message. I'm saying that an ImmutableError
wouldn't be a much different form of self-checking compared to the usual
TypeError/ValueError/RuntimeError you get when you pass wrong values/types to
methods/functions, or you violate invariants of objects. This has nothing to do
with dynamism, duck typing, dynamic binding and whatnot. Some objects have deep
invariants which can't be broken.

Why do you think we have a frozenset, for instance? By Mike's argument, we
shouldn't have it. And we should be able to use a regular mutable set as
dictionary key. Unittests will catch errors. Instead, we got two classes
instead of one, immutability is *enforced*, and sets can't be used as
dictionary keys. This is all good in my opinion, and follows the good rule of
"catch errors early".
[color=blue]
> Throw an exception that describes why it doesn't make sense to change
> that particular object instead.[/color]

*How* can I do? There is no language construct which lets me specifies an
exception to throw whenever someone modifies my object. *Even* if I got partial
support for immutable types (like __new__ which can be used to initialize
immutable objects).
[color=blue]
> As I said before, I think you're confusing the (in Python pretty
> non-existent) concept of encapsulation with Python's immutable types,
> which are immutable because the implementation demands it. (A fact I
> hope will disappear at some point.)[/color]

You seriously believe that strings, integers and tuples are immutable because
of implementation details? I believe they are part of a language design -- and
a good part of it.
--
Giovanni Bajo

[Giovanni Bajo]

Re: Making immutable instances

Mike wrote:
[color=blue][color=green]
>> There's a big difference. An immutable object has a totally different
>> semantic,
>> compared to a mutable object. If you document it to be immutable, and
>> maybe
>> even provide __eq__ /__hash__, adding attributes from it is surely
>> an user bug.
>> And surely a bug for which I'd expect an exception to be raised.[/color]
>
> Why is it "surely" a bug? It is arguable whether adding new
> attributes (vs. changing those that are already there) is, in fact,
> mutation.[/color]

If we agree that *changing* attributes is a bug for those classes, we're
already a step beyond in this discussion :)

About adding attributes, I agree that it's kind of a grey area. Per-se, there
is nothing wrong. My experience is that they give the user a false expectation
that the object can be modified. It ends up with an object with attributes
which can't be modified because that'd break invariants, and others which are
freely modificable.

In fact, the only thing that you are adding an attribute to *that* instance,
and not to all the *equivalent* instances (by definition of __hash__/__eq__) is
questionable and bug-prone. You might end up *thinking* you have that very
instance around, while you don't. In fact, with immutable objects, you are not
supposed to think in terms of instances, but rather of values. When I see a
string like "foobar" I don't care if it's the same instance of a "foobar" I saw
before. If I could add an attribute to "foobar", I might end up believing that
whenever I see a "foobar" around, it will have that attribute.

As you said, Python has rich data structures which lets you still find good
ways to carry around additional information. So why trying so hard to get into
trouble?
[color=blue]
> It sounds like what you may want are opaque objects where you can
> control access better[/color]

No that's a different issue. One example of my immutable classes is Point2D
(two attributes: x/y). Having it immutable gives it many useful properties,
such as a real value semantic.
--
Giovanni Bajo

[Mike Meyer]

Re: Making immutable instances

"Giovanni Bajo" <noway@sorry.co m> writes:[color=blue]
> Mike Meyer wrote:[color=green][color=darkred]
>>>> 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.[/color]
>> 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.[/color]
> 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.[/color]

Because *that's* the use case that you're preventing that I have
problems with.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

Adding an attribute can't break an invariant. The only way an
attribute can affect an invariant is if the invariant references
it. If it references it it, then it must exist - so I can't add it.
[color=blue][color=green][color=darkred]
>>>>> 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.[/color]
>>
>> 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.[/color]
>
> 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.[/color]

I didn't ask for a reason, I asked for a use case. Orthogonality is a
good thing, but so is generality. So I'll argue that the correct way
to make this situation orthogonal is to make builtin objects more
general by making it possible to add attributes to all of them.

On the other hand, practicality beats purity, and doing the above has
a significant cost in the current implementation, so leave it like it
is.
[color=blue]
> 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?[/color]

Unittesting doesn't change the language, and is part of any good
development methodology.

Assert is a shorthand for "if ... ; raise ...." that vanishes when you
turn on optimization. It's cleaner and more clearly expresses the
intent of the programmer, and saves a fair amount of boilerplate in
the best case.
[color=blue]
> Why do you think tuples are immutable and *enforced* to be so?[/color]

That you can't add attributes to a tuple is a detail of the
implementation; it's true for non-immutable types as well.
[color=blue][color=green]
>> 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.[/color]
> 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 :)[/color]

Well, that would explain why you think it's so important - it's where
you first encountered it. 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.

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

[Mike Meyer]

Re: Making immutable instances

"Giovanni Bajo" <noway@sorry.co m> writes:[color=blue]
> Björn Lindström wrote:
> Why do you think we have a frozenset, for instance? By Mike's argument, we
> shouldn't have it.[/color]

Not *my* arguments, certainly. Not unless you're seriously
misinterpreting them.

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

[Alex Martelli]

Re: Making immutable instances

Giovanni Bajo <noway@sorry.co m> wrote:
...[color=blue][color=green]
> > As I said before, I think you're confusing the (in Python pretty
> > non-existent) concept of encapsulation with Python's immutable types,
> > which are immutable because the implementation demands it. (A fact I
> > hope will disappear at some point.)[/color]
>
> You seriously believe that strings, integers and tuples are immutable because
> of implementation details? I believe they are part of a language design -- and
> a good part of it.[/color]

Definitely. When I first designed gmpy, I wanted to make its number
types mutable, thinking this might probably enhance performance, but I
double checked with Python cognoscenti first -- and the result was a
plebiscite for IMmutable numbers (at the time, I was sort of new at
Python, and didn't really get it, but now I do;-).


Alex

[Giovanni Bajo]

Re: Making immutable instances

Mike Meyer wrote:
[color=blue]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>> 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 :)[/color]
>
> Well, that would explain why you think it's so important - it's where
> you first encountered it.[/color]

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.
[color=blue]
> 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.[/color]

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.
--
Giovanni Bajo

[Paul Rubin]

Re: Making immutable instances

"Giovanni Bajo" <noway@sorry.co m> writes:[color=blue][color=green]
> > However, when you prevent a client from adding an attribute, you're
> > not merely making your objects immutable, you're making them
> > static.[/color][/color]

No I don't believe that. If an object is immutable, then
obj.serialize() should return the same string every time. If you can
add attributes then the serialization output will become different.

[Giovanni Bajo]

Re: Making immutable instances

Paul Rubin wrote:
[color=blue]
> "Giovanni Bajo" <noway@sorry.co m> writes:[/color]

[pay attention to the quoting, I didn't write that :) ]
[color=blue][color=green][color=darkred]
>>> Mike Meyer wrote:
>>>
>>> However, when you prevent a client from adding an attribute, you're
>>> not merely making your objects immutable, you're making them
>>> static.[/color][/color]
>
> No I don't believe that. If an object is immutable, then
> obj.serialize() should return the same string every time. If you can
> add attributes then the serialization output will become different.[/color]


I guess it might be argued that the method serialize() could return whatever
value it returned before, and that the added attribute could be "optional" (eg.
think of it as a cache that can be recomputed from the immutable attributes at
any time).

It's kind of a grey area. Surely, I would *not* mind if language support for
immutability prohibited this :)
--
Giovanni Bajo

[Giovanni Bajo]

Re: Making immutable instances

Mike Meyer wrote:
[color=blue][color=green]
>> Björn Lindström wrote:
>> Why do you think we have a frozenset, for instance? By Mike's
>> argument, we shouldn't have it.[/color]
>
> Not *my* arguments, certainly. Not unless you're seriously
> misinterpreting them.[/color]


Sorry then, I probably am. There must be a misunderstandin g somewhere.

What is your position about frozenset? By my understanding of your arguments,
it is a hand-cuffed version of set, which just prevents bugs that could still
be caught by testing. The same applies for the arbitrary restriction of not
allowing sets to be key dictionaries (with their hash value being their id).
--
Giovanni Bajo

[Mike Meyer]

Re: Making immutable instances

"Giovanni Bajo" <noway@sorry.co m> writes:[color=blue]
> Mike Meyer wrote:[color=green]
>> 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.[/color]
> 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.[/color]

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:
[color=blue][color=green][color=darkred]
>>> x = f()
>>> type(x)[/color][/color][/color]
<type 'tuple'>[color=blue][color=green][color=darkred]
>>> id(x)[/color][/color][/color]
136810980[color=blue][color=green][color=darkred]
>>> y = copy.deepcopy(x )
>>> y is x[/color][/color][/color]
False[color=blue][color=green][color=darkred]
>>> y == x[/color][/color][/color]
True[color=blue][color=green][color=darkred]
>>> f2(x)
>>> id(x)[/color][/color][/color]
136810980[color=blue][color=green][color=darkred]
>>> y == x[/color][/color][/color]
False[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

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.
[color=blue][color=green][color=darkred]
>>>> 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 :)[/color]
>> Well, that would explain why you think it's so important - it's where
>> you first encountered it.[/color]
> 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.[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

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@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Re: Making immutable instances

Paul Rubin <http://phr.cx@NOSPAM.i nvalid> writes:[color=blue]
> "Giovanni Bajo" <noway@sorry.co m> writes:[color=green][color=darkred]
>> > However, when you prevent a client from adding an attribute, you're
>> > not merely making your objects immutable, you're making them
>> > static.[/color][/color]
> No I don't believe that. If an object is immutable, then
> obj.serialize() should return the same string every time. If you can
> add attributes then the serialization output will become different.[/color]

There isn't a standard serialize method in Python, so I don't know how
you want to define it. I can think of perfectly reasonable definitions
of serialize where obj.serialize() won't always return the same string
on an immutable object, even if you don't allow adding attributes.

Personally, I'd argue that serialize shouldn't return the extra
attribute. If you want to add an attribute that gets serialized, you
need to subclass the immutable class, add the attribute there, and
extend serialize to include it. Whether or not that's reasonable
depends on how you want to define serialize.

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