[ python-Feature Requests-487738 ] weaklist

[SourceForge.net]

Feature Requests item #487738, was opened at 2001-11-30 20:36
Message generated for change (Comment added) made by rhettinger
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: Raymond Hettinger (rhettinger)
Date: 2005-07-27 09: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 06: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 20: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 18: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