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

[Blezek, Daniel J (CRD)]

Let me chime in here.

>     DG> Actually, though, rather than modifying vtkpython.py right
>     DG> away, I'd like to see Dan Blezek's idea of a module directory
>     DG> structure implemented: vtk.common, vtk.rendering,
>     DG> vtk.patented, etc. so that people can explicitly state in
>     DG> their programs which kits are desired.  This would also solve
>     DG> the installer problem.
> 
> We can surely wait but wouldn't it be painful accessing each vtk
> object via something like vtk.common.vtkBlahBlah etc. etc.?  Also,
> many times things change from one package to another.  What advantages
> does this approach give us?  Won't you still need magic code to load
> what is available at run time?

  IMHO, this is really a bad idea to have to know which kit a class is in.  I was thinking more of
loading classes in libvtkCommonPython.so into the vtk namespace, when you import vtk.common.  The
advantage is that you do not need to have Tkinter available for most of the kits(just Rendering), and
so now batch Python/VTK jobs become available.  I'm not good enough with python to know if this sort
of thing is possible though...  A "import vtk.graphics" would manage the dependancies it has on
vtk.common, etc... and only load what you need.

  A "import vtk" should default to loading everything compiled, i.e. Filters, Hybrid, Graphics,
Rendering, etc...  But the option of just loading a few packages should also be available.  We could
also have a vtk.test package to facilite testing under python, which is woefully under-represented.

$0.02,
-dan