Python3
Issue #4
new
PyCA compiles currently with no modifications using the current swig and python 3.3. However if you go to import it in ipython 3 you get errors because the python stuff that's shipped could use some 2to3 run on it. I've looked at this and it is mostly print statements that are updated, and a few ranges being treated as lists.
As far as I know, python2.6 and greater is compatible with that level of changes anyway, so I think it's safe to just update to using print as a function within our shipped *.py files.
Eventually even opensuse will move on to making python3 the default, and currently every distro i know is at at least 2.7, so I think it's fairly safe to do the in-betweener modifications for now but not use anything 3.x specific yet.
Comments (10)
-
reporter
-
(Reply via js...@sci.utah.edu):
Agreed, we should definitely make the modifications for python3 compatibility, and I haven't worried about compatibility for pre-2.7 anyway.
-
reporter
There are a couple places in the code where the python executable is called. For safety we could change this to python2. I think it's pretty universal now to have both python2 and python3 on the same system. Still looking into getting everything working for python3. I had some trouble last time I tried, but I have a local branch that I will push and keep rebased until we're ready to do the switch.
-
reporter
Running 2to3 at least makes the syntax work (e.g. print statements and some other stuff like xrange -> range and list comprehensions). Right now that's all that's done in the python3 branch. This builds, but is not runnable. If you try and load it, there are problems with for instance PyCA_alg.py wants to
import PyCA_types, which lies in the same directory.../python_module/Core. I've been able to work around this by editing the stuff directly in python_module. The stuff in Common and Display can be edited directly but Core is generated by numpy so I will do some digging and figure this part out. -
reporter
-
__init__.py for Core is just generated in the GenPythonModule.sh script, should be easy to change.
-
Ah nevermind, I see what you're talking about.
-
reporter
Trying to figure out if swig is capable of doing this properly. The problem is that the swig generated code is not using explicit relative imports such as
from . import PyCA_types.PS - btw @jspreston have you looked into SIP before? Supposedly has tighter C++ bindings for python, but not generalizable for other languages besides python/C++.
-
reporter
I still don't have a solution but I think this link has the important information. Will take another crack it in a while.
-
reporter
Oh, that is after adding -py3 to CMAKE_SWIG_FLAGS, which we'd need to do conditionally for python3 in CMakeLists.txt
- Log in to comment
I can make a branch and play with this possibly...