[Python-Dev] Py2.6 buildouts to the set API

[Aahz]

On Fri, May 18, 2007, Raymond Hettinger wrote:
>
> Here some ideas that have been proposed for sets:
> 
> * New method (proposed by Shane Holloway): s1.isdisjoint(s2).
> Logically equivalent to "not s1.intersection(s2)" but has an early-out
> if a common member is found.  The speed-up is potentially large given
> two big sets that may largely overlap or may not intersect at all.
> There is also a memory savings since a new set does not have to be
> formed and then thrown away.

+1 

> * Additional optional arguments for basic set operations to allow
> chained operations.  For example, s=s1.union(s2, s3, s4) would be
> logically equivalent to s=s1.union(s2).union(s3).union(s4) but would
> run faster because no intermediate sets are created, copied, and
> discarded.  It would run as if written: s=s1.copy(); s.update(s2);
> s.update(s3); s.update(s4).

+1

> * Make sets listenable for changes (proposed by Jason Wells):
> 
>     s = set(mydata)
>     def callback(s):
>          print 'Set %d now has %d items' % (id(s), len(s))
>     s.listeners.append(callback)
>     s.add(existing_element)       # no callback
>     s.add(new_element)            # callback

-3 -- that's an ugly wart on what is currently a nice, clean object.
This seems like a good opportunity for a Cookbook Recipe for a generic
listenable proxy class for container objects.  Note that I could argue
for the callback to be called even when the set doesn't actually change,
only when the set is attempted to be changed, which to my mind pushes
strongly for a recipe instead of extending sets.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Look, it's your affair if you want to play with five people, but don't
go calling it doubles."  --John Cleese anticipates Usenet