Python Module Exposure

[George Sakkis]

"Jacob Page" <apoco at cox.net> wrote:

> OK, you've convinced me now to support and, or, and xor between every
> combination of Intervals and IntervalSets, Intervals and IntervalSets,
> and IntervalSets and Intervals.

I'm sorry, this was not my intention <wink>.

> However, I'm not sure I  like the idea
> of an operation generating either one type or another.

I don't like it either; it makes the user's work harder by forcing him
to check the result's type, and then either process each type
differently or wrap Intervals into IntervalSets and deal with the
latter only.

> Thus, I'll have
> | and ^ operations between Intervals always return an IntervalSet
> instead of returning either an IntervalSet or an Interval.  & will
> return an Interval.  I suppose that means I should just have + do a
> union and - return an IntervalSet.  It will just have to be documented
> which types are to be expected for the return values depending on the
> operands.

This is better, but still I'm not sure if it's good enough. Splitting
the set of operators into those returning Interval and those returning
IntervalSet has to be documented of course, but nevertheles it is not
intuitive for the simple user who doesn't think about closed and
non-closed operations. It's a viable option though. The other two
options are:

- Return always an IntervalSet from all five operators (~, |, &, ^, -).
This is inconvenient for at least intersection and difference which are
known to be closed operations.

- Go back to your initial preference, that is don't support any
operator at all for Intervals. Given that in your new version there are
factories in IntervalSet as well, it's not as bad as before; simply the
user can create Intervals through the IntervalSet factories. You can
take this even further by disallowing (or discouraging at least) the
user to instantiate Intervals directly. An analogy is the Match type in
the re module. Match objects are returned by re.match() and re.search()
and they expose a set of useful methods (group(), groups(), etc.).
However if the user attempts to create a Match instance, a TypeError is
raised. Currently I like this option better; it's both user and
developer friendly :)

George