[WIP] Second set of Python 3 fixes

#1177 Merged at 8d3ce51
  1. MattT

With these changes, an installed yt (haven't yet gotten it to be single-codebase) gives me 15 test errors, 74 failures, mostly due to arithmetic changes I think.

Not yet ready, but nearly.

UPDATE 14JAN2015: I've updated this with the 3.1 release, and started looking at it again. Now using Python 3.4.2 to build. Currently, 24 errors, 69 failures.

Comments (34)

  1. Nathan Goldbaum

    This is awesome, thanks for the work on this Matt!

    Your comment in the PR description intrigued me: Is single-codebase a goal?

    1. MattT author

      Thanks! And, I am not yet sure. The main issue I think is going to be string formatting. I'm not really interested in using the future module, but we have six, so it might be feasible. I think the bytes/strings/formatting stuff might be the biggest hangup.

  2. astrofrog

    Thanks for working on this! I use Python 3.4 for production work, so looking forward to this :)

    A single code-base is nice, but it is a fair amount of work. You could always first support Python with 2to3 and only then slowly transition to a single code base.

  3. Michael Zingale

    Matt, where in these changes do you expect to find arithmetic changes that result in the errors/failures?

        1. MattT author

          Yes, but, we were really careful about that in the past. I think there is a side effect of a rounding issue which touches our slicing.

  4. MattT author

    My plan once this is working and passes all the tests is to decline this PR, graft the first two changesets on, then apply the diff from the PR on a few directories at a time. This will keep the commits relatively atomic and make bisection much easier.

        1. Nathan Goldbaum

          It means that the python2 tests pass and that it's probably safe to merge this PR now.

          We won't be able to guarantee python3 support until we have testing set up using python3.4.

  5. Nathan Goldbaum

    Besides the nits below, LGTM.

    Should we think about importing absolute_import and print_function from __future__ across the whole codebase?

  6. Michael Zingale

    I ran @MattT 's python3 bookmark version using python 2.x on a 3-d dataset examining the fields, plotting a line through the data. doing phase plots, volume rendering, and extracting a surface and everything looked like it should.

  7. Michael Zingale

    doing an install as @MattT suggested, I can import this into python3 (I'm running python 3.4.1). When I try a volume rendering, my script works fine in python2 but barfs with python3:

    Traceback (most recent call last):
      File "./vol.py", line 133, in <module>
        doit(plotfile, fname)
      File "./vol.py", line 87, in doit
        fields = [field], log_fields = [use_log])
      File "/home/zingale/.local/lib/python3.4/site-packages/yt-3.2dev-py3.4-linux-x86_64.egg/yt/visualization/volume_rendering/camera.py", line 194, in __init__
        efields = dd._determine_fields(self.fields)
      File "/home/zingale/.local/lib/python3.4/site-packages/yt-3.2dev-py3.4-linux-x86_64.egg/yt/data_objects/data_containers.py", line 494, in _determine_fields
        finfo = self.ds._get_field_info(ftype, fname)
      File "/home/zingale/.local/lib/python3.4/site-packages/yt-3.2dev-py3.4-linux-x86_64.egg/yt/data_objects/static_output.py", line 448, in _get_field_info
      File "/home/zingale/.local/lib/python3.4/site-packages/yt-3.2dev-py3.4-linux-x86_64.egg/yt/data_objects/static_output.py", line 283, in index
      File "/home/zingale/.local/lib/python3.4/site-packages/yt-3.2dev-py3.4-linux-x86_64.egg/yt/data_objects/static_output.py", line 328, in create_field_info
      File "/home/zingale/.local/lib/python3.4/site-packages/yt-3.2dev-py3.4-linux-x86_64.egg/yt/frontends/boxlib/fields.py", line 280, in setup_fluid_fields
        if field[3] in string.letters:
    AttributeError: 'module' object has no attribute 'letters'