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

[Prabhu Ramachandran]

hi,

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

    DJB> Prabhu, Good points, I hadn't thought of them.  I'm not sure
    DJB> I like having to call vtk.load_foo().  I would except to be
    DJB> able to use common, rendering, io immediately without loading
    DJB> them explicitly.

I understand.

    DJB>   Part of my thinking on my flawed package plans was due to
    DJB> the fact that I had just been down this road with Tcl.  In
    DJB> the end, Sebastian Barre ended up putting together something
    DJB> that went like this:

    DJB> % package require vtkrendering # vtkrendering has "package
    DJB> require vtkfoo" for all the packages it needs.

I dont know much Tcl at all so dont really understand what it means
and what implications the above have.  But it doesnt matter I guess.

    DJB> But I'd rather not have to do this in python:

    DJB> import vtkrendering; # import vtk is much, much cleaner

OK, thanks for the info.

    DJB>   So now I rescind my vote, and cast it to have one package
    DJB> called vtk that loads all the kits, and perhaps provides some
    DJB> GUI utilities, testing stuff as modules, if this makes sense,
    DJB> i.e.

    DJB> package require vtk package require vtk.testing

    DJB> # Test away

Here is my plan.

  (1) Ensure complete backward compatibility - so vtkpython will still
  be there - so will the other "used" classes like vtkRenderWidget.py
  and friends.

  (2) Provide the following:

      (a) A directory called vtk that can be populated with relavant
      stuff.

      (b) When you say 'import vtk' - *all* the kits will loaded into
      the vtk namespace.  Please note - *only* the kits will be loaded
      none of the testing/gui stuff will.

      (c) There are useful applications where someone might need to
      just use common or imagining or rendering, so here is my
      proposed directory structure:

$ ls vtk/
__init__.py filtering.py hybrid.py  io.py       patented.py  required.py
common.py   graphics.py  imaging.py parallel.py rendering.py
$

      (d) Now __init__ will import everything.  But if someone just
      wants common they can do:

	    from vtk.common import *
	    or (in Python 2.x)
	    import vtk.common as vtkcommon

      and they will get only the stuff in common.  There isn't any
      speed benefit in import times because vtk itself will have
      all the kits in it - but there might be speed improvements in
      resolving names when only one kit is used.  Anyway it would be
      nice to have things split up so if someone just wants common
      they can have it.

      (e) required.py will load all the required kits - i.e., common,
      filtering, io, imaging and graphics.  So actually you could do:

	    from vtk.required import *

      (f) I am contemplating if we also need an optional.py?

      (g) David mentioned being able to check if an import failed due
      to non-existence of the library or a linkage error.  Maybe I
      could add this too?

      (i) I plan on adding a test dir inside this directory and might
      just populate it for now with my test code.

      (j) Also plan on making a 'widget' directory.  Better
      suggestions for the name would also be appreciated.  widget will
      have all the TkWidget, GTK widget (which I plan on
      re-introducing unless someone has objections) etc.

That about covers it.  Suggestions are welcome.


    >> I hope my mail doesnt sound very offensive.

    DJB> Absolutely not!  In fact, this is one of the most cordial
    DJB> conversations I've ever had on a mailing list!

:)

    DJB>   We(python users) have a great opportunity to define VTK
    DJB> 4.0's python interface, and in my mind, a major version
    DJB> number change means that things can break, and people just
    DJB> have to deal with it.  So, by all means, let's talk about
    DJB> this, and do what makes the most sense.

Sure.  But I am not sure we want to make changes without backwards
compatibility.  Unless we can come out with rpms and dlls for all
combinations of Python, Tkinter etc. out there there will still be
folks stuck to using older versions.

thanks,
prabhu