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