[vtk-developers] New vtkpython.py - comments.

Blezek, Daniel J (CRD) blezek at crd.ge.com
Thu Oct 4 16:18:23 EDT 2001


Prabhu,

  Good points, I hadn't thought of them.  I'm not sure I like having to call vtk.load_foo().  I would
except to be able to use common, rendering, io immediately without loading them explicitly.

> OTOH, IMHO this interface is better:
> 
> import vtk
> vtk.load_common()
> vtk.load_rendering(dependencies=1)
> vtk.load_io()
> 
> a = vtkFloatArray()

  Part of my thinking on my flawed package plans was due to the fact that I had just been down this
road with Tcl.  In the end, Sebastian Barre ended up putting together something that went like this:

% package require vtkrendering
# vtkrendering has "package require vtkfoo" for all the packages it needs.

But I'd rather not have to do this in python:

import vtkrendering; # import vtk is much, much cleaner

In Tcl, Rendering is the only package that requires Tk, so you can't load it from Tcl without loading
Tk.  In Python, this shouldn't be a problem.  The overhead of loading all the VTK packages should be
marginal, I never notice it.

  So now I rescind my vote, and cast it to have one package called vtk that loads all the kits, and
perhaps provides some GUI utilities, testing stuff as modules, if this makes sense, i.e.

package require vtk
package require vtk.testing

# Test away

> I hope my mail doesnt sound very offensive.

Absolutely not!  In fact, this is one of the most cordial conversations I've ever had on a mailing
list!

  We(python users) have a great opportunity to define VTK 4.0's python interface, and in my mind, a
major version number change means that things can break, and people just have to deal with it.  So,
by all means, let's talk about this, and do what makes the most sense.

Take care,
-dan



More information about the vtk-developers mailing list