Python 3 compatibility

[bcipolli]

I don't think there are many packages being released with only Python 2.7 support these days; most have dual 2.7/3.x compatibility, others just have 3.x compat.

Current codebase doesn't support Python 3.x

[binarybottle]

Great point. Do you know where this codebase does not support 3.x?

[bcipolli]

I do not. I know that some of the print statements don't (that's what caused errors when I tried to run with 3.x), but I haven't really looked.

[satra]

nipype doesn't have 3.x support yet (in the pipeline), but won't happen till early next year or unless i get a free week sometime.

[bcipolli]

Trying to push those things forward. Lemme see what I can do this weekend with @alexsavio !

[binarybottle]

How did this effort go?

[bcipolli]

We got travis tests passing, but a few failures on circleci (another CI engine) that were odd and hard to debug. So... it should be good enough for you to proceed, but possible you might hit an issue for us to fix with nipype.

[binarybottle]

@bcipolli and @satra -- I have fixed all print statements, but don't know where mindboggle is not 3.x-compliant. I also don't know which dependencies might cause an issue (numpy scipy matplotlib pandas networkx vtk ipython nibabel nipype). Shall I make a break and work toward 3.x compatibility? If so, how would you recommend I best do this?

[bcipolli]

I usually start running the tests in Python 3.x locally, then debug the failures. I do search/replace to find and correct failures, rather than edit per-file.

The automated tools to do conversion are awful, IMHO, so I avoid them. I make great use of six, which I prefer over past and future. I also use the following website to help manage between the two: http://python-future.org/compatible_idioms.html

[binarybottle]

According to Chris Bare: "The strategy people seem to use is to write Python 2/3 compatible code, which mainly involves using the Python 3 idioms and importing back-ports from future." He recommended the same site as @bcipolli and said "You should also learn to love these lines:"

from future import absolute_import from future import division from future import print_function from future import unicode_literals from builtins import str from builtins import int from builtins import zip

Thankfully, I've only used absolute imports ("from mindboggle.x.y.z import..."), always divided floats, used parentheses and .format() for all my print statements, and simple alphanumeric strings throughout. I shouldn't have to worry about most instances of zip, since the they are used in loops: "for blah in zip(x)...," and I don't need to worry about int issues since I haven't used longs.

I did however change cPickle to pickle, changed all dict items, keys, and values to lists, and fixed any errors generated when building mindboggle with Python 3. Testing the resulting build now...

[bcipolli]

I actually hate the future package. I hate the old print syntax and absolute imports (less portable), and the hidden magic around unicode (that usually works, but can also lead to confusing errors when interfacing with code that needs explicit encodings)

Rather than pretend things are Python 2-ish (like all the imports listed above are), I prefer to migrate to python 3-ish, and use six to bridge the gaps between the two.

[binarybottle]

If possible, I would like to forego py2 and just embrace py3 and avoid all these workarounds. Unfortunately, I am running into installation conflicts with conda (which is in turn messing up circleci).

[satra]

changed all dict items, keys, and values to lists,

why would you do that?

I actually hate the future package.

@bcipolli - as you know we used this for nipype. i did find it much cleaner than the six approach which is more about making py 2 code py 3 usable, while future is about making py 3 code, py2 usable.

[binarybottle]

Sorry for being unclear. I followed http://python-future.org/compatible_idioms.html to treat dict keys, values, and items as lists:

keylist = heights.keys() -> keylist = list(heights) valuelist = heights.values() -> valuelist = list(heights.values()) itemlist = heights.items() -> itemlist = list(heights.items())

No need to import anything, and it works for py2 or py3.

[satra]

@binarybottle - ah that's fine.

[binarybottle]

Rewrote to Python 3, which is running fine...