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

[Blezek, Daniel J (CRD)]

Hi,

> Well, I am not at all convinced of this approach.  IMHO the whole
> point of splitting vtkpython into smaller packages is to segment the
> namespace.  The instant you say load common, imaging, filtering,
> etc. when you load rendering - all that nice splitting is gone.

  Ah!  I understand.  You are correct, and I agree.  However, in practice when you load rendering,
python gets all the VTK (not vtkpython) symbols loaded, so this comment was in many ways directed to
that fact.  While python does allow the nice splitting to occur, I do think that Rendering is quite
useless without PolyData(from Common) to feed through filters (from Filtering).  So it's less of a
"this is the ideal" and more "this is practical".  On the Tcl side, Jim Miller and I thought you
would want to have Filtering/Common if you needed to load Rendering.  I'm not sure exactly what the
balance should be!  As I elude to later, I had intended that each kit get loaded into the vtk
namespace, not it's own.  Perhaps this clears up some confusion?

> An even more immediate example, lets say we write a script that keeps
> track of all new classes added to a particular kit - say rendering.
> If we put common and other symbols in rendering we cant do this.  My
> point is there certainly are applications where one only wants the
> symbols exposed by rendering.

  This is another good point.  I was thinking that vtk.common would put all the vtk classes in the
vtk namespace, not in vtk.common.

> So basically, anything that rendering uses internally does not have to
> be exposed.  Even if you look at the way VTK is split rendering
> doesn't include common.  It presents a collection of classes that do
> rendering related things.  What rendering itself depends on is of
> little use to the end user.

  Rendering do not include common, but it does depend on Common.  This fact drove our thoughts about
having Rendering include Common, etc...  Rather than just load the classes from Rendering.  Rendering
isn't all that useful by itself.

> Maybe there is something I am missing.  I'd appreciate if you could
> give me concrete reasons as to why you want to load other symbols in
> the namespace of vtk.rendering.

  Ah!  I mis-spoke, I don't want vtk.common classes to be put into vtk.rendering, I just want them to
be automatically loaded.  If we decide to go with vtk.common.vtkFoo and vtk.rendering.vtkMapper, we
have the sticky problem of having to remember which kit each class is in.  It would be much less
burdensome for a Python developer to have vtk.common load it's symbols into vtk, and have Rendering
do the same, so you could do:

import vtk.common
fa = vtk.vtkFloatArray()

But you can also do:
import vtk.rendering
fa = vtk.vtkFloatArray()
pdm = vtk.vtkPolyDataMapper ()

  Sometimes email is a very difficult medium to communitate with, and I think I've blown it again...
8)

Take care,
-dan