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

[Prabhu Ramachandran]

hi,

>>>>> "DJB" == Daniel J Blezek <Blezek> writes:

    DJB>   I would have thought that vtk/common.py would simply load
    DJB> vtkCommonPython and return, possibly setting up some utility
    DJB> functions or classes.  A module like rendering would need to
    DJB> load (in order) common, filtering, graphics, and finally
    DJB> rendering(I don't remember if hybrid needs to be loaded as
    DJB> well).  So each module would handle it's dependencies, and
    DJB> load just what it needed.  In the case of vtk, it would load
    DJB> everything.

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.

Take for instance the case where you have to use a particular package
A, lets say A depends internally on B.  Just because someone wants to
use A doesn't mean they *must* also want to use B.  What A does
underneath is A's business not the users.  Take another example of a
module like Tkinter.  Tkinter uses the X11 libraries under Unix, just
because I use Tkinter my namespace shouldnt be "polluted" with X11
objects wrapped for Python!  Tkinter also wraps around _tkinter but
you usually don't access _tkinter directly.

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.

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.

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.

    DJB>   I would also like to see some of the ancillary files like
    DJB> vtkRenderWidget put under the vtk package.

Sure! shouldn't be a problem.  I'll first work on a decent interface
then we can slowly modify it and move whatever we want into it.

prabhu