Changes between Version 1 and Version 2 of Ticket #715, comment 204
- Timestamp:
- 08/16/12 14:16:10 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #715, comment 204
v1 v2 9 9 Instead, each triple of memory locations points to exactly one triple of references. The triple of references is popped off the dictionary as soon as any weak-refed member of the key triple was garbage collected. Note that the `if len(L)==0:` bit is not needed. 10 10 11 Another advantage: If the `TripleDic ct` is deallocated, then the strong references associated with the `TripleDict` will vanish as well, which wouldn't have been the case with the old code.11 Another advantage: If the `TripleDict` is deallocated, then the strong references associated with the `TripleDict` will vanish as well, which wouldn't have been the case with the old code. 12 12 13 Currently, there is only one bad situation I can think of: Let P be an object that can not be weak-refed, has a `TripleDict` T as an attribute, is used as a key in T, and has a `__del__` method. Then the reference cycle P->T->T._refcache->P will keep P alive. However, if any of the four assumptions does not hold, then P can be garbage collected. I think we can take that chance. 14 13 Currently, there is only one bad situation I can think of: Let P be an object that can not be weak-refed, has a `TripleDict` T as an attribute, is used as a key in T, and has a `__del__` method. Then the reference cycle P->T->T._refcache->P will keep P alive. However, if any of the four assumptions does not hold, then P can be garbage collected. I think we can take that risk. 15 14 Is there any question of yours that I forgot to address? 16 15