<div dir="ltr">Hi David,<div><br></div><div>Sounds great. I am glad that you are hooked on the wrappers :-) You have done a lot of wonderful work on them and as a big Python fan I am very grateful.</div><div><br></div><div>
PS: Sorry for the late reply. I was on vacation.</div><div><br></div><div>Best,</div><div>-berk</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 1, 2014 at 11:30 AM, 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">Hi Berk,<br>
<br>
Thanks for the insight into how this will impact your customers. I wasn't<br>
suggesting the the conversion of the tests be done now, or even before<br>
the core. And, yes, you're probably right that 2-to-3 is the way to go until<br>
the major sites are ready to switch to python3.<br>
<br>
For myself, there are two major wrapper-related tasks that have far higher<br>
priority than py3k:<br>
<br>
1) wrap enum types (so that enum types can be used as method args),<br>
and also wrap namespaces, since these are blockers for some code that<br>
I want to wrap.<br>
<br>
2) eliminate the "PyVTKClass" type, which relies on an obsolete metaclass<br>
mechanism (search for "Don Beaudry hack" if you're curious) and instead<br>
use python's unified type/class extension system.<br>
<br>
For #2, I'll see if I can put up a wiki page with more detail. But I don't have<br>
time to move forward on either 1 or 2 until the fall. And you aren't going<br>
to see me pushing for py3k, because I still have no need for it myself. I<br>
just want to be involved when the conversion occurs, because wrapper<br>
stuff is fun.<br>
<span class="HOEnZb"><font color="#888888"><br>
- David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Aug 1, 2014 at 8:11 AM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>> wrote:<br>
> Hi David and others,<br>
><br>
> I don't think that this workflow would work for us. Most of our<br>
> collaborators, specially in the supercomputing community, are going to take<br>
> a while longer to move to Python 3. So as a team, we need to continue to do<br>
> our day-to-day work using Python 2. So having to go through a 3-to-2<br>
> conversion mechanism would be very cumbersome. We would have to regularly<br>
> maintain 2 builds, do the development in 3 then move to the 2 build, test<br>
> etc.<br>
><br>
> I suggest taking smaller steps. Starting with porting of the core modules<br>
> (not the tests) and seeing what will be involved in maintaining both 2 and 3<br>
> versions (or a 2-to-3 conversion on the fly) would be my suggestion. Once we<br>
> can demonstrate the maintainability of this, I suspect that doing a 2-to-3<br>
> conversion on the fly for the tests would be pretty easy.<br>
><br>
> Best,<br>
> -berk<br>
><br>
><br>
> On Thu, Jul 31, 2014 at 4:15 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jul 31, 2014 at 6:44 AM, diego0020 <<a href="mailto:da.angulo39@uniandes.edu.co">da.angulo39@uniandes.edu.co</a>><br>
>> wrote:<br>
>> ><br>
>> > But I am also looking forward to this. Is there anything we could do to<br>
>> > push<br>
>> > support for python 3 forward?<br>
>><br>
>> 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>
>><br>
>> - David<br>
</div></div></blockquote></div><br></div>