[vtk-developers] Static methods in vtkPythonArgs

[David Gobbi]

On Tue, Mar 31, 2015 at 12:40 PM, E. Tadeu <e.tadeu at gmail.com> wrote:

> 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).
>

Twice as large as the default font.  You're writing an email, not a book.

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.

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.

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.

But, no, storing the temporary objects in the vtkPythonArgs won't work for
static methods, and I'm a fan of the static methods.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150331/b4e92f86/attachment-0001.html>