intiocean / pyinter Goto Github PK

Each infinity has one comparison-and-equality operator that returns False if the values are equal. It would be nice if this could be fixed.

Tests that show the issue:

assert NEGATIVE_INFINITY >= NEGATIVE_INFINITY
assert INFINITY <= INFINITY

Right now, it's not possible to write closed(3,4) | closed(5,6) | closed(4,5). It results in a TypeError saying that Interval object is not iterable.

The current workaround is to wrap the Interval object into a IntervalSet, e.g. closed(3,4) | closed(5,6) | IntervalSet([closed(4,5)]) which is not very convenient.

A simple way to support the first notation could be to add:

other = IntervalSet([other]) if isinstance(other, Interval) else other

It could actually be a good idea to have Interval objects also supporting IntervalSet. In that case, an easy way could be to add:

if isinstance(other, IntervalSet):
  return other.union(self)

pyinter.IntervalSet([pyinter.open(1, 7), pyinter.closedopen(5, 10)])

Should create IntervalSet((1, 10)) instead of what it currently creates IntervalSet((1, 7), [5, 10))

• code and tests for IntervalSet
• sphinx documentation. available here: http://pyinter.readthedocs.org
• Add example with date times
• setup continous integration on travis ci
• add to pypi
• How to install
• Add code coverage badge
• Create a version range as a concrete usable example (pkg_resources versioning)
• ensure all functions have docstrings describing the inputs and outputs
• compare with https://crate.io/packages/interval/ and https://crate.io/packages/pyinterval/

Currently it's very difficult to tell if a user accidentally passed in strings to pyinterval.closedopen. For instance, in the case of:

bad_interval =  pyinterval.closedopen('100','200')

The repr() and str() modules don't show the quotes around the values, so it looks like you passed in integers. The only way to tell is by using

bad_interval._data._lower_value
bad_interval._data._upper_value

I understand you want the module to be type-agnostic, which is admirable, but making repr() look like:

['100','200')

instead of:

[100,200)

might make it easier to debug problems.

pyinter is incredibly slow; adding a thousand intervals requires a million operations, because add() loops over all the existing elements in the set.

add() (and similar functions) should take advantage of the sorted order and only touch elements which intersect other.

I'm just beginning to use this in an application and it's integers I'm interested in.

So far I'm standardizing on a helper function lambda i: pyinter.closedopen(i,i+1)

Next I'm planning to implement an iterator of iterators, where each interval in an IntervalSet is mapped to a standard range object and the whole mess is iterated to enumerate, in order, the integers in the set.

Assuming this works reasonably well I'll hack it into the code and docs and add a pull request. If you have a better suggestion I'm all ears.

The comparison operators should return a NotImplemented object instead of raising a NotImplementedError.

See https://docs.python.org/3.6/library/constants.html#NotImplemented

In the docs they are flipped.

It makes the use of it nicer. You can then do something like this:

IntervalSet(interval1, interval2, interval3, ...)

Instead of having to make a list out of your items before passing them in

IntervalSet([interval1, interval2, interval3])

The reason it was created in this way to start with was to match the Python inbuilt set initialisation but I don't think it needs to match.