[vtk-developers] Static methods in vtkPythonArgs

E. Tadeu e.tadeu at gmail.com
Tue Mar 31 16:42:21 EDT 2015


David,

  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!


On Tue, Mar 31, 2015 at 4:37 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> 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/bf638277/attachment.html>


More information about the vtk-developers mailing list