<div dir="ltr">David,<div><br></div><div>  Using std::string in the code generated by vtkWrapPython.c would work, but it would be a more complicated solution and also a bit wasteful as you said (I think that in Python 3 the temporary object would not be necessary anymore, since it provides the beautiful PyUnicode_AsUTF8AndSize).  I was hoping for the removal of the static methods, since they are sparsely used and since the vtkPythonArgs instance creation does not seem to be something that would impact on performance.  I will try another solution (probably changing the Python default encoding), thanks!</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 31, 2015 at 4:37 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 dir="ltr"><span class=""><div class="gmail_extra">On Tue, Mar 31, 2015 at 12:40 PM, E. Tadeu <span dir="ltr"><<a href="mailto:e.tadeu@gmail.com" target="_blank">e.tadeu@gmail.com</a>></span> wrote:<br></div></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Sorry about that, it's a plugin that renders Markdown in e-mail, and I configured the style sheet to use a slightly larger font (but it should not be HUGE :P).</div></blockquote><div><br></div></span><div>Twice as large as the default font.  You're writing an email, not a book.<br></div><div><br></div><div>I don't think that there is a policy that states whether VTK is supposed to prefer utf-8 over the current system encoding (this is a big problem on Windows where the default code page is never utf-8).  So it would be worth bringing that up as a separate topic before the python wrappers are modified.</div><div><br></div><div>A possible solution would be to store the resulting string in a std::string instead of using a "char *". This would require changing vtkWrapPython.c so that it created it's local string variables as "std::string" instead of "char *", and then used c_str() to get a "char *" to pass to VTK. This would be a bit wasteful if the original string was not a PyUnicode object, but then again, for Python 3 _all_ strings will be unicode.</div><div><br></div><div>Either that, or another method can be added to vtkPythonArgs that returns not only the "char *", but also returns a python object that the wrapper code (i.e. code generated by vtkWrapPython) can decref.  This is more efficient than the std::string solution mentioned above.  I'm sure there must be a precedent somewhere in the current python wrappers, because conversion via a temporary isn't uncommon.</div><div><br></div><div>But, no, storing the temporary objects in the vtkPythonArgs won't work for static methods, and I'm a fan of the static methods.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div> - David</div></font></span></div></div></div>
</blockquote></div><br></div>