Python 3 support

[rth]

In the long term perspective, it would probably be good to add Python 3.x support alongside 2.7.

The corresponding test environments, could then be uncommented in .travis.yml and appveyor.yml...

[bsmurphy]

This is very true. I've been thinking about this over the past few weeks, and I think I'll finally have some time to actually work on this coming up. Clearly, the print statements will need to be changed, but that should just be a matter of putting parentheses around all the things to be printed (apparently this works in both Python 2 and Python 3, which I didn't know). I haven't really used Python 3, so do you have any thoughts on anything else that could clearly go wrong?

[rth]

I don't think there would be that many changes to make the code base compatible with both Python 2.7 and 3.x (see this cheat sheet ). First thing could be to add,

from __future__ import absolute_import
from __future__ import division
from __future__ import print_function
from __future__ import unicode_literals

at the top of every .py file to make 2.x behave like 3.x. Then replace all print 'this' with print('this') and other minor issues if any arise when running the test suite ( six module would be very usefull there).

The only real issue I see is that the Cython BLAS binding I did won't work with 3.x as far as I remember. So the solution is either to try fixing that, or ask for >=scipy-0.16 as minimum requirements which includes those bindings now (and this transition should be done at some point anyway). I'll look in that last point as soon as I can (probably mid november) but for now I suppose we can just disable the compilation of the Cython backend in setup.py for Python 3.x (for instance checking with if six.PY3 etc.).

[bsmurphy]

Alright, I've updated the code so that it should be Python 3 compatible. (The new version is also on PyPI.) The tests on TravisCI and AppVeyor are passing with when run with the Python 2.7 and Python 3.4 platforms. I've also updated the setup script to try to better address the Cython compiler issue with Windows (as discussed in issue #8). Now the script attempts to build the Cython extensions regardless of operating system or build_ext compiler settings, and if the build fails it falls back to a pure Python implementation without building the Cython extensions. (I followed the example set here.) Also, the setup script currently does not build the Cython extensions for Python 3. This can be easily changed in the future.

One thing that I am slightly concerned about is the way I'm currently using strings in the setup script. I couldn't use the little from __future__ import unicode_literal thing to just force all the strings to be unicode, because setuptools.Extensions requires the name of the extension to be a native string in Python 2.7 rather than unicode. So I left all the strings as unspecified format strings, which seems to be working OK regardless of whether the script is run on Python 2.7 or Python 3.4. But I might be missing something subtle here. Let me know what you think.

[rth]

Awesome! This works really well. About the unicode in setup.py, I think leaving as it is now should be good (I have not seen anyone using that import in setup.py anyway). So this solves the issue on the Python 3 support, and I'll look into updating Cython bindings as as soon as I can.