<div dir="ltr">Hi David and others,<div><br></div><div>I don't think that this workflow would work for us. Most of our collaborators, specially in the supercomputing community, are going to take a while longer to move to Python 3. So as a team, we need to continue to do our day-to-day work using Python 2. So having to go through a 3-to-2 conversion mechanism would be very cumbersome. We would have to regularly maintain 2 builds, do the development in 3 then move to the 2 build, test etc.</div>

<div><br></div><div>I suggest taking smaller steps. Starting with porting of the core modules (not the tests) and seeing what will be involved in maintaining both 2 and 3 versions (or a 2-to-3 conversion on the fly) would be my suggestion. Once we can demonstrate the maintainability of this, I suspect that doing a 2-to-3 conversion on the fly for the tests would be pretty easy.</div>

<div><br></div><div>Best,</div><div>-berk</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 31, 2014 at 4:15 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, Jul 31, 2014 at 6:44 AM, diego0020 <<a href="mailto:da.angulo39@uniandes.edu.co">da.angulo39@uniandes.edu.co</a>> wrote:<br>


><br>
> But I am also looking forward to this. Is there anything we could do to push<br>
> support for python 3 forward?<br>
<br>
</div>There has been some discussion about converting all of the python<br>
tests and examples, which is a part of the process where extra<br>
manpower would be a big asset.  I imagine that the conversion will<br>
go something like this:<br>
<br>
1) Someone will run 2to3 on all the python code, and then make<br>
sure that it can be byte-compiled with python3 (it will be too early<br>
at this stage to actually run the code, but making sure that it<br>
byte-compiles will be a good first step).<br>
<br>
2) Lots of people will then pick through the code to fix conversion<br>
errors and to make sure that the code actually looks like good<br>
python3 code.<br>
<br>
3) Finally, someone will add some CMake magic to VTK so that if VTK<br>
is built against python2, cmake will run 3to2 on all of these new python3<br>
files and put the equivalent python2 code into the VTK build<br>
directory.  This is the magic that is needed to make sure that VTK<br>
will be able to support both python2 and python3.<br>
<br>
So any assistance with the above process would be a big help.  In<br>
particular, it would be very useful if someone could verify that item<br>
(3) is even feasible: in the end it might be necessary to have hand-<br>
written python2 and python3 exist side-by-side instead of using<br>
automatic conversion.  It _should_ be feasible, since the VTK<br>
tests used automated tcl-to-python conversion for many years,<br>
and python3 to python2 should be much easier than tcl to python.<br>
<span class="HOEnZb"><font color="#888888"><br>
 - David<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the VTK FAQ at: <a href="http://www.vtk.org/Wiki/VTK_FAQ" target="_blank">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtkusers" target="_blank">http://public.kitware.com/mailman/listinfo/vtkusers</a><br>
</div></div></blockquote></div><br></div>