Feature Requests item #487738, was opened at 2001-11-30 20:36 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=487738&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 4 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-27 14:00 Message: Logged In: YES user_id=31435 FYI, ZODB has a WeakSet implementation, in utils.py here: http://svn.zope.org/ZODB/trunk/src/ZODB/ I wouldn't add this to the core -- it's very specific to ZODB's needs. For example, it actually uses a weak value dictionary, because ZODB can't assume the set elements are usably comparable or hashable. One thing that "should be" addressed in the core is explained in a long comment there: the core weak containers don't supply a sane way to iterate over their weakly referenced containees. You either risk unpredictable "dict changed size during iteration" exceptions, or unboundedly worse gc behavior (read the comment for more detail). The ZODB WeakSet implementation has to break into the weak-value dict implementation to supply a partially sane way to iterate over its elements ("partially" means it's not incremental, and exposes weakrefs to the client; OTOH, it doesn't suffer mystery "dict changed size" exceptions, and plays nicely with gc). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-27 10:02 Message: Logged In: YES user_id=80475 Weaksets would not be warranted unless the use cases demonstrated needs for methods unique to sets (intersection, union, etc). Otherwise, weakdictionaries would suffice and we could avoid bloating the module. Also, I'm not sure weaklists are a good idea. First, it is not clear that the subscription use case can be reliably implemented with gc as the primary means of unsubscribing -- traditionally, that is done with an explicit unsubscribe() call issued by the subscriber. Second, weaklists only have a differential advantage when it comes to maintaining insertion order. It is not clear that that feature is really useful. What is clear is that the approach incurs extra costs for maintaing order and O(n) removal time. When order tracking is necessary, there are reasonable implementations using weakkeydictionaries with the entry values being a sequence number indicating creation order. With that data structure, group notification is still simple: for subscriber in sorted(wkd, key=wkd.__getitem__): self.notify(subscriber, message) This approach incurs an O(n log n) sort cost for each group notify but has only an O(1) deletion cost which is an improvement over weaklists. The only way I see around the deletion time issue is to have a weakdoublylinked list which would allow O(1) deletions, appends, and O(n) iteration. None of this came up on the referenced newsgroup posting because there was NO active discussion. IOW, the idea has not shown any demand and has not been through the basic due diligence needed to tease out the best approach. I recommend leaving this as a recipe until we see a battlehardened implementation, a convincing use case, and some user demand. ---------------------------------------------------------------------- Comment By: S. Kochen (g-lite) Date: 2005-07-27 07:51 Message: Logged In: YES user_id=890349 I'm not sure if either is more useful than the other, they both seem to have their advantages. It looks like a set would work for the links I mentioned, but I'd personally like to have the ability to connect to a signal/event with priority, thus needing a list. A weak set could possibly be implemented on top of WeakKeyDictionary? Have weak sets already been implemented somewhere? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-07-26 21:19 Message: Logged In: YES user_id=3066 This might be interesting to have. Would this be more useful than, say, a weak set? Ordering may be important for the publish/subscribe use case, at least to ensure predictability. I've not looked at the contributed code, so can't make any comment on that. ---------------------------------------------------------------------- Comment By: S. Kochen (g-lite) Date: 2005-07-26 19:16 Message: Logged In: YES user_id=890349 Mind if I bring this back up? This doesn't seem to be in yet. I didn't look at the implementation, but as for motivation... Andres mentioned his original motivation on a list: http://aspn.activestate.com/ASPN/Mail/Message/python-list/929285 I've also seen it duplicated in this recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056 I'd like to see it in for the same reason. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 00:35 Message: Logged In: YES user_id=3066 Oops, I meant to adjust the priority on this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 00:31 Message: Logged In: YES user_id=3066 Needs motivation. Without an need for the data structure, this will be rejected. Lowering priority and marking this for consideration for Python 2.3; it's too late to add this for Python 2.2. Set to "pending" while awaiting an explanation of the motivation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 20:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=487738&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
