"Jacob Page" <[EMAIL PROTECTED]> wrote: > George Sakkis wrote: > > As I see it, there are two main options you have: > > > > 1. Keep Intervals immutable and pass all the responsibility of > > combining them to IntervalSet. In this case Interval.__add__ would have > > to go. This is simple to implement, but it's probably not the most > > convenient to the user. > > > > 2. Give Interval the same interface with IntervalSet, at least as far > > as interval combinations are concerned, so that Interval.between(2,3) | > > Interval.greaterThan(7) returns an IntervalSet. Apart from being user > > friendlier, an extra benefit is that you don't have to support > > factories for IntervalSets, so I am more in favor of this option. > > 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. 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. George -- http://mail.python.org/mailman/listinfo/python-list
