Making immutable instances

[Mike Meyer]

Steven D'Aprano <steve at REMOVETHIScyber.com.au> writes:
> On Sat, 26 Nov 2005 04:59:59 -0500, Mike Meyer wrote:
>> Steven D'Aprano <steve at REMOVETHIScyber.com.au> writes:
>>> On Fri, 25 Nov 2005 23:20:05 -0500, Mike Meyer wrote:
>>>> If you've got a use case, I'd be interested in hearing it.
>>> frozenset perhaps? If it were needed once, it could be needed again.
>> That's not a use case, that's an example. 
> Fine. "I want to use a set as a dictionary key, but dict keys must be
> immutable."

Except that dict keys don't have to be immutable. The docs say (or
imply) that, but they're wrong. We're discussing new wording in
another thread.

>> And not a very good one, as
>> it's not at all clear that the restriction is intentional in that
>> case. After all, the same restriction applies to every builtin type,
>> including the mutable version of frozenset.
> Every builtin type, including mutable sets, is immutable???

No. I think you missed the entire second half the thread.

> I think we're talking at cross purposes. I'm talking about immutable
> instances. What are you talking about?

I'm talking about being able to add attributes to an instance. You
can't add an attribute to *any* builtin type. This is an
implementation detail. I consider it to be a wart in the language, but
an acceptable one, because the costs of fixing it are much worse than
the costs of working around it, and practicality beats purity.

>>> The obvious case would be for a class where distinct instances that
>>> compare equal but not identical map to the same value in a dict.
>> How does the ability to add attributes to the instances of the class
>> change that behavior?
> Er, who said it did?

You did. We're looking for a use case for adding the ability to mark a
class as having instances that you can't add an attribute to. You
suggested this as such a use case.

>> The best reason Ben could come up with is that it makes
>> finding bugs a bit easier. 
> Are you sure that was Ben? Maybe I missed it.

No, I'm no sure it was Ben - I didn't go chase down the
reference. It's the best use case *from anyone* so far, though.

> All joking aside, I think having immutable custom classes, with or without
> restricting attribute creation, is no worse than (say) Python's name
> mangling.

There are well-defined facilities for creating read-only
attributes. Is there a difference between an immutable object you can
add attributes to, and an object that has nothing but read-only
attributes?

>> Of course, that a feature has a lot in common with features from
>> un-Pythonic languages doesn't make it ipso facto unPythonic. After
>> all, practicality beats purity. So what's the practical application
>> for such a feature? What's the use case?
> Class instances match by identity when used as keys, not equality. That's
> over-strict: why should Parrot("Norwegian Blue") map to a different item
> from Parrot("Norwegian" + " Blue") just because the first instance has a
> different memory location to the second?

Uh - HTH did we get here?

> Please note, I do not expect -- and would not want -- the default
> behaviour to change. Most class instances presumably should be mutable,
> and therefore mapping by ID is the right behaviour.

The default behavior is right for in many cases. For those that it's
not right, you can fix it. Proper definition of the Parrot class will
insure that Parrot("Norwegian Blue") == Parrot("Norwegian" + " Blue")
always evaluates to True.

> But some class instances shouldn't be mutable, and should match as keys by
> equality not identity: we would expect Fraction(num=1, den=2) to match
> Fraction(num=2, den=4) as a key.

And you can do that with Python as it exists today (and one of these
days I'll get back to my Rational class that does that...). There's no
need for any changes to the language to deal with this case.

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