[Aahz] > Thing is, it *is* possible to have a mutable and hashable object. The > hashable part needs to be immutable, but not the rest. Consider dicts in > the generic sense: the key needs to be immutable, but the value need not, > and it certainly can be useful to combine key/value into a single object. > Now, I'm still not sure that your analysis is wrong, but I wanted to be > very, very clear that hashability is not the same thing as immutability. [Guido] > For frozensets, shallow copy should return self; for sets, shallow > copy should return set(self). > > In both cases, deepcopy() should do something like _deepcopy_list() > and _deepcopy_tuple(), respectively. That is, deepcopying a set is > pretty straightforward, but must store self in the memo first, so that > (circular!) references to self are correctly deepcopied. Deepcopying > a frozenset will be a little harder, because there can still be > circular references! _deepcopy_tuple() shows how to do it. Thanks guys. It's all clear now. The good news is that nothing special has to be done to implement deepcopying. The copy.deepcopy() function is already smart enough to do the right thing when the type provides a __reduce__() method for pickling. Raymond
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4