<div dir="ltr">Hi All,<div><br></div><div>I think that it is a very good point that py3k support is needed in</div><div>order for vtk-python to move forward as a teaching tool for new</div><div>students. We're actually very lucky that the scientific computing</div><div>community has decided to stick with python, because moving</div><div>to a whole new language would be _really_ tough.</div><div><br></div><div>As far as the wrappers go, currently the C++ PyVTKClass and</div><div>PyVTKObject extension types provide an old-style (python 1.5)</div><div>metaclass mechanism. Moving forward, each VTK class can</div><div>be its own extension type... I looked at the wrapper code over</div><div>the weekend, and it's a few days' work that I can probably get</div><div>done sometime in May or June.</div><div><br></div><div>After that, the wrappers will have to be modified to handle the</div><div>changes that py3k made to PyInt and PyLong, and then all the</div><div>necessary #ifdefs will have to be added so that both py2 and</div><div>py3k versions of the wrappers will compile.</div><div><br></div><div>Fortunately, VTK has an abundance of python tests, including</div><div>many tests in Common/Core/Testing/Python for special features</div><div>of the wrappers. So I don't think we're likely to break anything</div><div>(e.g. numpy support) in the transition.</div><div><br></div><div> - David</div>
</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 10, 2015 at 5:55 AM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Arnd,<div><br></div><div>Your assessment sounds in the right ballpark. I don't foresee more issues. In fact, most of the Python code in VTK is in the testing suite. I'd hope that any errors there would be caught easily. The huge majority of non-testing Python code is in Wrapping/Python/vtk, which is something like 40 files. I volunteer taking care of most of those files. I am pretty sure that we can find volunteers to fix the tests. So upgrading the Python files is really not that hard. Wrapping is the main challenge.</div><div><br></div><div>Best,</div><div>-berk</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Mar 10, 2015 at 3:45 AM, Arnd Baecker <span dir="ltr"><<a href="mailto:arnd.baecker@web.de" target="_blank">arnd.baecker@web.de</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">As a follow-up concerning the conversion of the .py files:<br>
I have run the current 6.2 release through pylint<br>
with --py3k option.<br>
<br>
Excluding everything from the ThirdParty directory<br>
(which for example contains Twisted 14.0.0 which<br>
is not yet ported to Python 3)<br>
this is only approx 780 python files.<br>
<br>
One gets a total of 3130 violations spread over 745 files.<br>
<br>
Out of these there are:<br>
- 2325 violations W1618<br>
(missing `from __future__ import absolute_import`)<br>
Adding this line actually might not be necessary, it just indicates<br>
that this behaviour is the default on python 3.<br>
- 552 violations E1601<br>
print statement.<br>
This can be easily solved using<br>
from __future__ import print_function<br>
and converting all print-statements to print(...)<br>
- 53 violations E1604<br>
syntax change in raise<br>
<br>
So this leaves some further 200 violations spread over 72 files.<br>
These have to be looked at individually.<br>
Several warn about the change in division<br>
(which can be solved using ``from __future__ import division``<br>
and using // instead of the current usage of /.<br>
<br>
Overall that part seems doable with reasonable effort<br>
(But maybe I am seeing things too optimistic<br>
or I am overlooking something ...).<br>
In the end this would mean that all examples and tests<br>
could (in principle) be run both on python 2 and python 3<br>
without any further code changes.<br>
Moreover, ThirdParty already contains SixPython<br>
which could be used if there are changes like range vs. xrange etc.<br>
<br>
Are there automatic tests runs<br>
a) for the python code?<br>
b) to determine code-coverage for VTK<br>
(including the python side)?<br>
This would help to prevent any regression<br>
during the above steps.<br>
<br>
Concerning the first two points of David:<span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1) VTK wrapping still uses old-style classes. I've been meaning to fix this.<br>
2) Basic compile issues and cross-compatibility for py3 and py2 -<br>
we received a patch that fixes some of these issues.<br>
</blockquote></span>
I have no clue how much work this is...<br>
<br>
Best, Arnd<br>
<br></div></div><span class="">_______________________________________________<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>
Search the list archives at: <a href="http://markmail.org/search/?q=vtkusers" target="_blank">http://markmail.org/search/?q=vtkusers</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>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>