On Thursday 01 July 2004 10:43 am, Michael Hudson wrote: > Would "why?" be an apposite question? I'm sure there is a reason, but > I haven't seen it yet :-) Absolutely! I hinted at the reason in my original email, but it was not made explicit that it was the reason. The change allows the WeakValueDictionary to be implemented in a much more memory-efficient manner. The current implementation causes each entry to create and retain the following objects in addition to the actual key: - a weakref to the value, with a callback - a function object used as the callback; a new function is created for every entry, since it contains a reference to the key in a default parameter value - a weakref to the WeakValueDictionary itself, to avoid creating a cycle. The last object could be removed without any change to the C implementation; all that's really needed is a single weakref to the WeakValueDictionary that can be shared by all such callbacks. Using a subclass of the weakref.ref type (KeyedRef in the patch), the key can be stored as an attribute of the weakref, allowing a single object to be created and retained as overhead (with the allocation for that object being at most 8 bytes larger than a stock weakref). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
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