Python Module Exposure
gsakkis at rutgers.edu
Sun Jul 10 08:11:45 CEST 2005
"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
- The set of integers is not closed under division: int / int ->
- The set of real numbers is not closed under square root: sqrt(real)
- 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.
More information about the Python-list