Python Module Exposure

[George Sakkis]

"Jacob Page" <apoco at cox.net> 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