George Sakkis wrote: > "Jacob Page" <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
