Python 3 compatibility

[leouieda]

Python 2.7 will be officially deprecated by 2020. We should start making the code compatible with Python 3 to ease the transition in the future. We can make the code run in both Python 2.7 and Python 3.* using the future package. This is already in use in the fatiando.inversion package.

Not too much needs to be changed for this to work. Mainly:

• print is now a function. Fix: from __future__ import print_function at the start of all modules and examples.
• The / operator no longer performs integer division. Ex: in py2 1/2 == 0 in py3 1/2 == 0.5. Fix: from __future__ import division and all division will behave like py3. To get integer division, use 1//2.
• xrange no longer exists and range behaves like xrange (returns a generator, not a list). Fix: from future.builtins import range.

These are the changes that affect most of the code. There are other issues with metaclasses and the super function but these won't affect many modules.

What we need to get this started: test coverage. The only we'll know if our changes break something and that things work in Python 2.7 and 3.4/3.5 is to have extensive unit tests. This way, we can change the code and automatically know if something is broken in any version.

We should try to get started in the compatibility with any new code. The goal is to have Python 3 compatibility by Fatiando v0.5, which should be release in the middle of 2016.

Update: We didn't make the v0.5 goal for Python 3 support. The current plan is to make v0.7 work in Python 2 and 3 (3.5+). This would be our last release that works in Python 2. From then on, we can drop support for Python 2 entirely and stop worrying about this. Read more about why/how we're doing this at http://www.python3statement.org

[mtb-za]

Looks like Mayavi might finally be moving over to Python3 as well: http://docs.enthought.com/mayavi/mayavi/auto/changes.html?highlight=python3 which I think was out major block, correct?

[leouieda]

Yep, that was the only block actually. But from this PR it seems that it still requires a lot of work and the master branch of some other projects.

All other dependencies work in Python 3. Porting Fatiando itself won't be too much of a problem once I get the tests properly organized and up the coverage a bit. I'm hoping to get this started this year still.

[eusoubrasileiro]

finally got some time to look at this...
I am just using python 3 now so I was wondering ... now I know
nice @leouieda! there we go!

[leouieda]

Just FYI, the current plan is to clean up the code base and increase the test coverage first. This will lay the ground work for the Python 3 compatibility, which should be very straight forward.

If Mayavi enables Python 3, I'd even be inclined to drop Python 2 support one release after the Python 2/3 release.

[eusoubrasileiro]

@leouieda thanks

About mayavi it seams it is ready for python3 look at these
http://stackoverflow.com/questions/19138418/get-mayavi-working-with-python-3
(last answer)
and this Issue already closed

[leouieda]

Yes, I've seen those. But by ready I mean "conda install mayavi" should work. The way it is now, it requires the user to compile VTK. Imagine the emails we'd get from people trying to do that.

[eusoubrasileiro]

yeah I get understood

[rafaelmds]

@leouieda
Regarding to print function

some tests use python2 print format like

print i,

inside a loop, which results in one line separated by whitespaces ending with a line break.

The problem is that simply rewriting to

print(i, end=' ')

adds a trailing whitespace after the last element before the line break,
and in turn it causes test coverage to fail.

For example:

_____________________ [doctest] fatiando.utils.SparseList ______________________
366 Example::
367
368 >>> l = SparseList(5)
369 >>> l[3] = 42.0
370 >>> print(len(l))
371 5
372 >>> print(l[1], l[3])
373 0.0 42.0
374 >>> l[1] += 3.0
375 >>> for i in l:
Expected:
0.0 3.0 0.0 42.0 0.0
Got:
0.0 3.0 0.0 42.0 0.0

In the last one there's an extra space character which caused the fail.

Please let me know if I'm missing something "very clear" or if the test code must have to be changed to adapt to new print format.

[leouieda]

@rafaelmds thanks for reporting. These tests are usually a bit sensitive because they were poorly designed. It's not worth spending time on this in the main repo. A lot of this code is completely unnecessary now (like the SparseList in your example).

I started working on the modernized versions of fatiando internals. For now, I'm focusing on the gridding part (https://github.com/fatiando/verde) because that coincides with some of my research. It's Python 3 from the start and the code there is a lot better. Turns out a lot of the stuff I implemented in Fatiando is already there in pandas, scipy, xarray, scikit-learn, etc.

Verde already does most of what fatiando.gridder did but better. If you want to help out, that's where the future is :) I'll start work on the geometric and gravmag parts soon as well. I'm laying out some issues that need to be implemented in https://github.com/fatiando/verde/issues