Support Python 3

[jakirkham]

• Add Python 3.5 and 3.6 to the Travis CI matrix.
• Install NumPy and SciPy with wheels on Travis CI.
• Update pip on Travis CI (particularly for Python 2.7).
• Open files as binary when working with pickle.
• Use print function with Python for 2/3 compatibility.
• Workaround a bug in Python 3's C API. ( https://bugs.python.org/issue11587 )
• Make various fixes to the code for Python 3 compatibility.
• Fix registration of the input_indices function.
• Use ^ with NumPy bool arrays instead of -.
• Handle unicode in regularizer.
• Handle Python errors thrown in regularizer.
• Workaround a SciPy incompatibility between Python 2/3. ( https://github.com/scipy/scipy/issues/6099 )
• Cherry picked the fix from PR ( https://github.com/lucastheis/cmt/pull/30 ).

[FlorianFranzen]

Looks good. Thank you for your work and the detailed commit log.

I am not sure why 3decc40 is included, as it has been merged with #30.

@lucastheis Can you take a closer look at 771706f and a8290de.

[jakirkham]

I am not sure why 3decc40 is included, as it has been merged with #30.

This was created before that PR was merged and has simply not been updated. Was trying to get rid of already fixed test failures while debugging. Will rebase it out.

[jakirkham]

Have rebased.

@lucastheis Can you take a closer look at 771706f and a8290de.

As a consequence, these have changed to ( https://github.com/lucastheis/cmt/commit/6842b96a93c7e9af238c3fa3f6a3ccb913ace260 ) and ( https://github.com/lucastheis/cmt/commit/bdfb406df4ce83d68c4028395bdf9d99fca78512 ) respectively. Though their content should be the same.

[jakirkham]

One thing does concern me with this Python 3 support, am seeing a segfault pretty reliably in the tools_test.py, which doesn't occur on Python 2.

I'm not entirely sure what is causing it. That said, I did notice a lot of the C++ code was not properly checking Python exceptions and handling them (see last paragraph). It is possible this segmentation fault is some Python 2/3 incompatibility that would have raised an exception, but was not properly handled. So it comes back as a segfault instead.

Unfortunately this is not likely something I'm going to have time to debug/fix. That said, I have been seeing this segfault crop up since I started this PR, which suggests that this was already an issue in the existing code. Also the aforementioned commits do show how one goes about handling these sorts of exceptions. The NumPy codebase also has some really good examples. Often people like to use gotos to keep all the exception propagating code in one place (normally at the end of the function after the last return).

C Python Exception Handling: Any time a Python C API function returns a PyObject* or other pointer, one should be checking to see if it is NULL. Alternatively if an int is returned, one should be checking to see if it is -1. When one of these respective situations occurs, one must handle the exception. This means either clearing it somehow and doing some workaround or returning NULL/-1 respectively. Note there is no need to set the exception when propagating the error as it is already set. If the exception is not handled, bad things usually happen (e.g. segfaults). Also if NULL or -1 get passed to other Python C API functions or returned by any functions here, other strange things can happen (e.g. again segfaults). More details about this can be seen in the docs of Python 2 and Python 3

[lucastheis]

Thanks for all your work. Looks good on first glance. I will need a bit more time to understand why some tests fail before merging.