Dolfin fails to import with python 2.7.10

[Stephan Kramer]

When building dolfin in an environment with python 2.7.10, the resulting python fails to import with the following backtrace:

skramer@gyre:~/tmp/dolfin$ python -c "import dolfin"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/skramer/.hashdist/bld/profile/ar54j3cbpg5r/lib/python2.7/site-packages/dolfin/__init__.py", line 16, in <module>
    from . import cpp
  File "/home/skramer/.hashdist/bld/profile/ar54j3cbpg5r/lib/python2.7/site-packages/dolfin/cpp/__init__.py", line 42, in <module>
    exec("from . import %s" % module_name)
  File "<string>", line 1, in <module>
  File "/home/skramer/.hashdist/bld/profile/ar54j3cbpg5r/lib/python2.7/site-packages/dolfin/cpp/common.py", line 132, in <module>
    __pythonversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[2], tmp[4], tmp[6]])))
ValueError: invalid literal for int() with base 10: 'a'

I believe this is due to the way it is trying to convert the python version hex string PY_VERSION_HEX (see line 29 of dolfin/swig/version.i) into seperate major, minor and micro version numbers. This conversion only works for single digit (in decimal) version numbers. For instance the PY_VERSION_HEX I get with my python 2.7.10 (this is python from Debian unstable) is 0x2070ac1

[Johan Hake]

Can you check if this patch fixes the problem?

diff --git a/dolfin/swig/version.i b/dolfin/swig/version.i
index 8dace25..1af3497 100644
--- a/dolfin/swig/version.i
+++ b/dolfin/swig/version.i
@@ -33,6 +33,6 @@ unsigned int dolfin_pythonversion() { return  PY_VERSION_HEX; }
 tmp = hex(dolfin_swigversion())
 __swigversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[-5], tmp[-3], tmp[-2:]])))
 tmp = hex(dolfin_pythonversion())
-__pythonversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[2], tmp[4], tmp[6]])))
+  __pythonversion__ = "%d.%d.%d"%(tuple(map(lambda x: int(x, 16), [tmp[2], tmp[4], tmp[6]])))
 del tmp, dolfin_pythonversion, dolfin_swigversion
 %}

[Stephan Kramer]

Great, thanks! Works as it should (minus the spurious two spaces at the beginning of the pythonversion definition). My only concern would be that this will break again with python 2.7.16 - assuming they'll keep on bringing out regular bug fix releases for 2.7.

[Johan Hake]

Good point! The white space just lurked in there. I think this patch should fix all our trouble to python 2.255.255

diff --git a/dolfin/swig/version.i b/dolfin/swig/version.i
index 8dace25..6d65aac 100644
--- a/dolfin/swig/version.i
+++ b/dolfin/swig/version.i
@@ -33,6 +33,6 @@ unsigned int dolfin_pythonversion() { return  PY_VERSION_HEX; }
 tmp = hex(dolfin_swigversion())
 __swigversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[-5], tmp[-3], tmp[-2:]])))
 tmp = hex(dolfin_pythonversion())
-__pythonversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[2], tmp[4], tmp[6]])))
+__pythonversion__ = "%d.%d.%d"%(tuple(map(lambda x: int(x,16), [tmp[2], tmp[3:5], tmp[5:7]])))
 del tmp, dolfin_pythonversion, dolfin_swigversion
 %}
#!diff

[Johan Hake]

Fix issue 525 where the micro and minor part of the python version could not be larger than 9.

→ <<cset 747e8acefb0f>>

[Johan Hake]

Above fix now in next.

[Johan Hake]

Fixed by: 747e8acefb0f4402cba6444a59391892fd3dd0a7

[Jan Blechta]

I think this patch should fix all our trouble to python 2.255.255

Great! Now only Py3, Py4, ..., Py255 issues are remaining :)