Making immutable instances

[Steven D'Aprano]

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."


> 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???

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


>> 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?


>> In any case, I'm not the one claiming that I need custom immutable
>> classes. I'm just suggesting that there is nothing non-Pythonic about
>> them. If Ben thinks he needs them, I'm sure he has put *far* more thought
>> into it than I have. I know Ben in RL, and he is not someone to make snap
>> judgements about turning Python into Some Other Language Just Because.
> 
> I claim that the dynamic natture of Python - which is exemplified by
> things like duck typing and the ability to add attributes to nearly
> everything on the fly - is a fundamental part of what makes Python
> Python. 

I can't disagree with you there.

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


> But so do type declarations, static
> namespaces, private and protected attributes, and a slew of similar
> B&D features that are pretty much anathema to dynamic languages. This
> feature fits *very* well in languages that have those features, and
> poorly in languages that reject them, which includes Python.

Perhaps. But I don't object to *mild* B&D, the sort you can get out of
relatively easily. You know, handcuffs, maybe a few ropes, but not
lock-them-up-in-the-oubliette-and-throw-away-the-key *wink*

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


> 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?

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.

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.



-- 
Steven.