Python Module Exposure

[Jacob Page]

George Sakkis wrote:
> "Jacob Page" <apoco at cox.net> wrote:
> 
>>I selected option one; Intervals are immutable.  However, this doesn't
>>mean that __add__ has to go, as that function has no side-effects.  The
>>reason I chose option one was because it's uncommon for a mathematical
>>operation on two objects to return a different type altogether.
> 
> Mathematically what you described corresponds to sets that are not
> closed under some operation and it's not uncommon at all; a few
> examples are:
> - The set of integers is not closed under division: int / int ->
> rational
> - The set of real numbers is not closed under square root: sqrt(real)
> -> complex
> - The set of positive number is not closed under subtraction:
> pos_number - pos_number -> number
> - And yes, the set of intervals is not closed under union.

Yes, but I wasn't talking about mathematical operations in general; I 
was talking about mathematical operations in Python.  Example: 6 / 5 
doesn't yield a float (though I heard that might change in future 
versions).  If the union of two integers yielded a set of integers, then 
it'd make more since for the union of two Intervals to yield an 
IntervalSet.  But it doesn't.  Just as set([2, 6]) creates a set of two 
integers, IntervalSet(Interval(...), Interval(...)) creates a set of two 
intervals.

> On another note, I noticed you use __contains__ both for membership and
> is-subset queries. This is problematic in case of Intervals that have
> other Intervals as members. The set builtin type uses __contains__  for
> membership checks and issubset for subset checks (with __le__ as
> synonym); it's good to keep the same interface.

Good catch.  I think I've made similar mistakes for a few of the other 
functions, too.

Thanks for your help.