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

[Prabhu Ramachandran]

hi,

Okay, I think there is too much confusion.  I will first address your
points generally and then specifically reply to your message.  

As I see it:

  (1) You want it to be easy to access parts of the set of objects
  that vtkpython provides.

  (2) You specifically want it such that all 'dependencies' are roped
  in.  

  (3) You want to be able to do something like this:

      import vtk.rendering
  and then do
      a = vtk.vtkFloatArray()
      p = vtk.vtkPolyDataMapper()
  etc. etc.

  (4) You also would want to say 

      import vtk

  and access all vtk objects, right?

Are there more requirements that I missed?

Ok here are my problems with these:

By adding requirement (2) you loose requirement (1).  I explained this
earlier.  It may be that you want to use vtkFloatArray along with
PolyDataMapper, but then again you may want vtkBMPWriter too!  So
where do you draw the line?  If you want a package to be split into
smaller pieces you had better know what you want and where it is, dont
you think so?  How is a user to know that vtk.rendering has what it
does?  If vtk.rendering just has vtk/Rendering stuff then atleast the
user just looks at the local directory to figure out what is there.
In this case, a user has to look at all the python import stuff and
then look at Common, Hybrid, Graphics, Rendering to see if the class
is in.

So IMHO only folks who specifically want rendering alone will use
vtk.rendering.  The others use import vtkpython.

Requirement (3) is AFAIK non-standard!  When you import vtk.rendering
it is not a good idea to mess with vtk's namespace.  When you do
import vtk.rendering you are importing the vtk packages' __init__.py
and then getting to the rendering package inside it.  The namespace
that you have asked for to be made available is in vtk.rendering.
Putting all vtk.rendering stuff into vtk is totally non-standard and
IMHO wrong.  Polluting your namespace is your business so if the user
chooses to do

from A import *

fine.  The user takes the risk of handling name conflicts.  But we
shouldnt do this when someone imports vtk.  Lets say there is module A
that wants to access vtk.rendering and module B that wants only
vtk.common and then A imports B then B's vtk will change simply
because A polluted it with all that rendering stuff!!  Basically the
approach is not clean.

OTOH, IMHO this interface is better:

import vtk
vtk.load_common()
vtk.load_rendering(dependencies=1)
vtk.load_io()

a = vtkFloatArray()

But again its not completely perfect and suffers from the A, B import
problems but atleast the user knows what is going on.

I know of no way to handle issue 3 and 4.  If you want 4 then import
vtk.rendering will actually call import vtk underneath and that will
mean the spiltting is no longer possible, atleast the way you want it.

AFAIK, any approach that attempts to resolve these issues will not be
clean.

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

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

I understand what you mean but dont understand why you need this?  Why
not simply import the whole thing in one big go as we do now.  I
understand that name lookups will become slow with 650 odd new names
in the vtk namespace but you dont get speed for nothing. :)

    >> 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.

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

Sure, but if you look at it that way no part of VTK is useful in
itself.  A pipeline is useless without any particular segment!  Again
a reason for importing everything?? :)

Of course all these opinions are mine and this is only my vote. :)

I hope my mail doesnt sound very offensive.

prabhu