3 ms·

Yes, hence my suggestion to introduce an immutable adaptor class. Then all containers (sets, dictionaries, etc.) gain those abilities.

pdonis 10y ago
> hence my suggestion to introduce an immutable adaptor class What does this gain you over just doing tuple(obj) (or the equivalent--tuple(d.items()) for a dictionary, for example) when you want to make it immutable for use as a dict key?
- colanderman 10y ago
  It can be implemented copy-on-write. It can have more compact storage if the runtime is smart. It can continue to efficiently support lookup (e.g. tuple(d.items()) would not).
  - pdonis 10y ago
    > It can be implemented copy-on-write. Which only makes sense if the underlying mutable object is mutated. But if the underlying mutable object is mutated, the adaptor instance, if it is immutable, can no longer have the same value as the underlying mutable object. So the "adaptor" is no longer an adaptor; it's just a separate immutable object with the value that the mutable object had originally. I.e., it's just the same as tuple(d.items()) or whatever. If by "copy-on-write" you just mean that two different containers that both store the same immutable value, say a string, can both point to the same memory storing that value, and the mutable container's pointer only changes if a new value is stored at that key/index, Python already does that; for example, tuple(d.items()) does not create new storage for the items themselves, it points the tuple to the same objects that are contained in the dict at the time of the call to d.items(). > It can have more compact storage if the runtime is smart. A tuple in Python does have more compact storage than a list, dict, or set. > It can continue to efficiently support lookup Same issue as above; this only matters if the underlying object is mutated, in which case an immutable "adaptor" can no longer have the same value, so lookup on the adaptor isn't the same as lookup on the underlying mutable object. Lookup on the adaptor is just lookup on the immutable value, which is easily made efficient.

pdonis 10y ago

> hence my suggestion to introduce an immutable adaptor class What does this gain you over just doing tuple(obj) (or the equivalent--tuple(d.items()) for a dictionary, for example) when you want to make it immutable for use as a dict key?

colanderman 10y ago
It can be implemented copy-on-write. It can have more compact storage if the runtime is smart. It can continue to efficiently support lookup (e.g. tuple(d.items()) would not).
- pdonis 10y ago
  > It can be implemented copy-on-write. Which only makes sense if the underlying mutable object is mutated. But if the underlying mutable object is mutated, the adaptor instance, if it is immutable, can no longer have the same value as the underlying mutable object. So the "adaptor" is no longer an adaptor; it's just a separate immutable object with the value that the mutable object had originally. I.e., it's just the same as tuple(d.items()) or whatever. If by "copy-on-write" you just mean that two different containers that both store the same immutable value, say a string, can both point to the same memory storing that value, and the mutable container's pointer only changes if a new value is stored at that key/index, Python already does that; for example, tuple(d.items()) does not create new storage for the items themselves, it points the tuple to the same objects that are contained in the dict at the time of the call to d.items(). > It can have more compact storage if the runtime is smart. A tuple in Python does have more compact storage than a list, dict, or set. > It can continue to efficiently support lookup Same issue as above; this only matters if the underlying object is mutated, in which case an immutable "adaptor" can no longer have the same value, so lookup on the adaptor isn't the same as lookup on the underlying mutable object. Lookup on the adaptor is just lookup on the immutable value, which is easily made efficient.