I am interested in having slicer work with python 3 as I am already using python 3 in other parts of my workflow, and would be nice to not have make my scripts compatible across both.
I have heard that this is planned but didn’t know if was formerly documented all the pieces that will be affected by the transition?
What would be required to do this, what pieces need to be updated and made compatible?
would be nice to not have make my scripts compatible across both.
If you are not using feature specific to python 3, your scripts will be compatible. To ensure this is the case, you could also make sure of the Six: Python 2 and 3 Compatibility Library, it is available in Slicer.
all the pieces that will be affected by the transition?
Assuming your code is forward compatible with python 3 (you could for example look at Cheat Sheet: Writing Python 2-3 compatible code, most of the infrastructure change will be transparent for your project.
Indeed, the Slicer build-system API that will be unaffected, only the implementation of CMake function like SlicerMacroBuildModuleQtLibrary will be changed internally. And other change will also be specific to Slicer core, and will be related to class like qSlicerScriptedUtils. But that should not affect the building and distribution of your project.
Leaner extension packages would be nicer and probably version requirements could be managed more flexibly if python packages would be downloaded dynamically. However, it should be possible to install extensions from file, without network connection.
Slicer has been updated to only support building against Python3 and all python scripts available in the main Slicer code base are only compatible with Python3.
@jcfr Should we add a wiki page or online spreadsheet where we can quickly add any issues that we find (to make sure we don’t forget about them or work on them in parallel)? Mantis would be too heavyweight for this.
For example, I’ve just found that restart() Python function does not work anymore (has no effect).