Spans is a pure Python implementation of PostgreSQL's range types. Range types are convenient when working with intervals of any kind. Every time you've found yourself working with date_start and date_end, an interval may have been what you were actually looking for.
Spans has successfully been used in production since its first release 30th August, 2013.
Spans exists on PyPI.
$ pip install Spans
Documentation is hosted on Read the Docs.
Imagine you are building a calendar and want to display all weeks that overlaps the current month. Normally you have to do some date trickery to achieve this, since the month's bounds may be any day of the week. With Spans' set-like operations and shortcuts the problem becomes a breeze.
We start by importing
>>> from datetime import date >>> from spans import daterange
daterange.from_month we can get range representing January in the year
>>> month = daterange.from_month(2000, 1) >>> month daterange(datetime.date(2000, 1, 1), datetime.date(2000, 2, 1))
Now we can calculate the ranges for the weeks where the first and last day of month are
>>> start_week = daterange.from_date(month.lower, period="week") >>> end_week = daterange.from_date(month.last, period="week") >>> start_week daterange(datetime.date(1999, 12, 27), datetime.date(2000, 1, 3)) >>> end_week daterange(datetime.date(2000, 1, 31), datetime.date(2000, 2, 7))
Using a union we can express the calendar view.
>>> start_week.union(month).union(end_week) daterange(datetime.date(1999, 12, 27), datetime.date(2000, 2, 7))
Do you want to know more? Head over to the documentation.
Use with Psycopg2
To use these range types with Psycopg2 the PsycoSpans.
For a project of mine I started using PostgreSQL's
tsrange type and needed
an equivalent in Python. These range types attempt to mimick PostgreSQL's
behavior in every way. Deviating from it is considered as a bug and should be
I appreciate all the help I can get! Some things to think about:
- If it's a simple fix, such as documentation or trivial bug fix, please file an issue or submit a pull request. Make sure to only touch lines relevant to the issue. I don't accept pull requests that simply reformat the code to be PEP8-compliant. To me the history of the repository is more important.
- If it's a feature request or a non-trivial bug, always open an issue first to discuss the matter. It would be a shame if good work went to waste because a pull request doesn't fit the scope of this project.
Pull requests are credited in the change log which is displayed on PyPI and the documentaion on Read the Docs.