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

[Aaron Brady]

> -----Original Message-----
> From: python-dev-bounces+castironpi=comcast.net at python.org [mailto:python-
> dev-bounces+castironpi=comcast.net at python.org] On Behalf Of Raymond
> Hettinger
> Sent: Friday, May 18, 2007 8:35 PM
> To: python-dev at python.org
> Subject: [Python-Dev] Py2.6 buildouts to the set API
> 
> 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.

It sounds -really- good.

> * 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).

This pleads for elsewhere adding operation in chains.  Sort on multiple keys
is addressed by itemgetter (IMO also should be built-in).  But dict.update,
a list append, a deque pop could use these.  When-do-you-ever is out of
stock and ships in a week.

> * 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

This one calls for subclassing, a la observer pattern.

In that vein, some subclassing operation could use a list of
pattern-matching / semantic membership.  E.g.
def every_add_op( self, op, ***data ):
	call_a_hook( ***data )
	op( ***data )

Rings of ML.  Support could be provided with

def __init__...
	for x in ( add, update, intersection_update ):
		def my_x( self, ***data ):
			call_a_hook( ***data )
			x( ***data )
		setattr( self, x, my_x )

But you need to know which operations are destructive/constructive, but we
can't go back and annotate the whole stdlib.  Though I agree that some level
of programmatic interference could be useful.

Academic concern which shoots 50-50 in the real world.  I may be tempered
with too much beauty (Beautiful is better than ugly.), not enough market.
You're all in it for money.