[vtk-developers] Python packages: status, suggestions.

[Blezek, Daniel J (CRD)]

All,

  My comments:

I don't mind 

>>> import vtk

to get at all of vtk.  This is handy, and for 99% of Python/VTK users, fits the bill nicely.  I also
like the:

>>> import vtk.common

construct(regardless of what it actually loads).  This effectively hides all the other
packages/classes that I didn't want.

I don't like:

>>> import vtk.vtk


The GUI packages are a good choice.

-dan

> -----Original Message-----
> From: Prabhu Ramachandran [mailto:prabhu at aero.iitm.ernet.in]
> Sent: Friday, November 02, 2001 2:05 AM
> To: vtk-developers at public.kitware.com
> Subject: [vtk-developers] Python packages: status, suggestions.
> 
> 
> hi,
> 
> Here is an update on what is the current status and the problems with
> the current code and a proposed solution.
> 
>   Currently, the Python packages are all in a seprate vtk sub
>   directory and it is possible to import parts of VTK via various
>   modules inside the vtk sub directory.  Further, to import all of VTK
>   all that is needed is
> 
>   import vtk
>   a = vtk.vtkFoo()
> 
>   Parts of VTK are accessible via
> 
>   import vtk.common
>   a = vtk.common.vtkFoo()
> 
>   Note: The issue with loading modules that aren't installed has been
>   resolved in a recent CVS commit.  The following will (correctly)
>   raise an exception if you dont have parallel compiled.
> 
>   >>> import vtk
>   >>> import vtk.parallel
>   Traceback (most recent call last):
>     File "<stdin>", line 1, in ?
>     File 
> "/skratch/prabhu/vtk/cvs/VTK/Wrapping/Python/vtk/parallel.py",
>  line 7, in ?
>       from libvtkParallelPython import *
>   ImportError: No module named libvtkParallelPython
> 
> 
> However there are problems with the current code.
> 
>   When vtk is imported it 'silently' imports *all* the VTK classes
>   into its namespace.  So although vtk.common will give you just the
>   common classes vtk itself will have *everything*.  This is clearly
>   not ideal.  This is the biggest problem with the current approach.
> 
> 
> Splitting vtk into smaller packages is definitely nice since it
> becomes possible to access parts of VTK so it might not be a good idea
> to abandon the package approach.  I proposed changing the vtk
> directory name and doing something like this:
> 
>   import vtkpkg.vtk 
> 
>   where vtkpkg.vtk will now contain all of VTK and vtkpkg will not.
> 
> Although reasonable, the name isn't so great.  Other names were also
> suggested but they also didnt seem to appeal the Python users.
> 
> I was thinking of another naming convention that folks might like.
> Here it is.
> 
>   from vtk import vtk
>   a = vtk.vtkFoo()
> 
>   # or
>   from vtk.vtk import *
>   a = vtkFoo()
> 
>   # package access
>   from vtk import common
>   a = common.vtkCommonFoo()
> 
>   import vtk.common
>   a = vtk.common.vtkCommonFoo()
> 
>   import vtk.gui.tk as vtk_tk
>   v = vtk_tk.vtkTkRenderWindow() # or something.
>   
> etc. etc.
> 
> Advantages:
> 
>   (1) In this case the names are still small and neat.
> 
>   (2) The base vtk package will *not* have all of VTK silently
>   imported into its namespace.
> 
>   (3) Package access is straightforward just like before.
> 
> Disadvantages:
> 
>   (1) It is a bit inconvenient doing:
> 
>       from vtk import vtk
> 
>   It also sounds a little funny.  Some may also dislike using vtk.vtk
>   and might prefer
> 
>       import vtk
> 
> 
> However, I think this disadvantage is not too bad.  Afterall the
> package access gives people a lot of other things, most notably a way
> to integrate all vtk python related stuff into one package rather than
> have a large bunch of files that do different things.
> 
> Also, as regards the gui stuff I propose the following:
> 
>   import vtk.tk
>   v = vtk.tk.vtkTkRenderWidget()
> 
>   import vtk.gtk
>   v = vtk.gtk.vtkTkRenderWidget()
> 
> I dont think the gui sub package is essential at all.  Its pretty
> obvious that tk/gtk/wx/anygui/qt are all toolkits.  Sticking them
> inside a gui dir makes access more painful.
> 
> I'd appreciate feedback on these proposals.  If we have a consensus I
> can make the necessary changes.  Once this is done we can slowly
> populate the package with the gui code, clean it up and also add much
> needed testing code to the tree.
> 
> Thanks,
> prabhu
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at public.kitware.com
> http://public.kitware.com/mailman/listinfo/vtk-developers
>