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

[Prabhu Ramachandran]

hi,

>>>>> "DG" == David Gobbi <dgobbi at irus.rri.ca> writes:

    DG> If the installer won't work unless everything is explicit,
    DG> then go for it.  You have to admit, though, the current
    DG> vtkpython.py is very pretty to look at ;)

Sure, it definitely looks very nice!  Actually, I can work around the
problems caused by the lack of an explicit import.  I was just
thinking about the "correctness" of this approach.

    DG> One problem with the current vtkpython.py that would not be
    DG> fixed by making it 'explicit' is this: if one of the
    DG> 'optional' kits refuses to load because of e.g. an unresolved
    DG> run-time symbol then no error is generated.

How about adding some code to detect this then?  At the end of a build
one could write into a file, information on which kits were built and
then use these to explicitly load the modules?

    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?

    >> The vtkLoadPythonTkWidgets.py code also runs into trouble with
    >> the installer.  The code implicitly assumes that sys.path is a
    >> string - which it isnt when you use the installer.  This is
    >> easily modified by adding a simple try block.  Can I make this
    >> modification and commit it?

    DG> Do it.

Okay, will do so in a little while.

prabhu