Make the Python interface compatible with Python3

Registered by Johan Hake on 2011-06-22

I big show stopper for migrating or enabling Python3 for the Python interface of DOLFIN has been removed. NumPy, is since version 1.5, Python 3.2 compatible. SWIG 2.0.3 also generate Python3.2 compatible code.

The largest work would be to port all Python code to Python3 syntax. Tools exist for this:

  http://wiki.python.org/moin/2to3

and to add it as an option in the configuration process. As long as we do not use any of the new features, we should be able to make our code python2.6 _and_ python3 compatible as all of the new syntax is valid in Python 2.6.

Blueprint information

Status:
Started
Approver:
None
Priority:
High
Drafter:
Johan Hake
Direction:
Approved
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Started
Milestone target:
None
Started by
Garth Wells

Related branches

Sprints

Whiteboard

We should register this Blueprint for each Python-based project, since if 2.6 <-> 3.2 is compatible, we can tackle each project separately.
JH: I think it is 2.6 <-> 3.1 and 2.7 <-> 3.2

Yes, I wondered if I should have registered it at the fenics level.

Also: The compatibility goes for part of the syntax. It is not until 2.7 most of the new features are included. This means that you can do:

  print("stuff"), raise Exception("bar"), ...

in python2.6. But then there is some old syntax in 2.6 that is not compatible with 3.2 and vice-verse.

One of the things to do:
https://blueprints.launchpad.net/ffc/+spec/stop-using-old-exception-syntax

JH: I suggest that in dolfin we only use the built in cpp.error. So the Python and C++ interface uses the same error messages.

MSA: We can apply the 2to3 tools for specific changes like print statement, raise syntax, possibly others. This can be done directly in the codebase once and for all. However we cannot just apply all 2to3 changes and use the same code for 2.x and 3.x even though , because that will lead to serious performance regressions, in particular in UFL and probably FFC. The code will have to be maintained for 2.x and automatically transformed to 3.x, as recommended here:
"The officially recommended way of supporting both Python 2 and Python 3 is to maintain the source code in a Python 2 version and convert it with 2to3 for Python 3 support. That means you will have to run 2to3 each time you have made a code change so you can test it under Python 3."
http://python3porting.com/strategies.html

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.