Python is an open source interpreted, object-oriented, high-level programming 
language with dynamic semantics. Its high-level built in data structures, 
combined with dynamic typing and dynamic binding, make it very attractive for 
Rapid Application Development, as well as for use as a scripting or glue 
language to connect existing components together. 

 o Relatively simple syntax, but a full fledged language.  

 o Extensive standard libraries include string manipulation, subprocesses, 
   file access, math, sockets, time. 

 o Fairly easy to make C code callable from Python, normally by writing
   a layer of "glue" code.  In some cases the glue code can be automatically
   generated using mechanisms like SWIG (used for GDAL).

 o Python has built in data types for things like lists, tuples, and 

 o Python is the scripting language for OpenEV, and Peppers and a good
   chunk of each is written directly in Python.  Atlantis has also implemented
   Python access to GDAL and the OGR projection services. 

 o Python has many rich extension packages, including NumPy (Numeric Python)
   an interpreted array math environment vaguely like Matlab or IDL.

 o Python is not very declarative, thus relatively few errors can be found
   at compile time.  It is much more easy to write code that compiles, but 
   fails at runtime than in more declarative languages like Java.  Python
   is a weakly typed language. 

 o Debugging environments do exist for Python; however, I haven't had much
   success with them.  On the plus side, the fact that python "crashes" are
   normally just generates run-time exceptions which report a traceback can
   make fixing errors fairly easy.  I personally, have often sunk back to the
   level of debugging by adding print statements in Python.

   I think it would be useful for us to review python IDE environments like
   IDLE to see if we should be using them. (talk to Paul about his experiences)
 o Python is compiled on the fly, so generally instead of the 
   edit-compile-link-run cycle, you just have the edit-run cycle.  However,
   generally speaking you do have to restart the application which is often
   the "heavy" part of the whole debugging cycle. 

 o It is possible to use a conventional debugger (ie. gdb) to debug problems
   in C modules called from Python.  However, you can't get any meaningful
   traceback information from the Python side of stuff. 

Python Bindings

Example of implementing a Gtk style binding for a C function to be
accessable from Python.  Gtk style bindings are used for the bulk of the
OpenEV C entry points (and Peppers?).  

The declarations file (gv.defs) contains information on each class, and 
method along with the methods return type, and types passed to it.  

(define-object GvRasterLayer (GvLayer))

(define-func gv_raster_layer_zoom_set
  ((GvRasterLayer layer)
   (int max_mode)
   (int min_mode)))


Once processed C wrapper code is created that presents a function style
interface to the method.  To make it operate like a method on a class, the
following Python wrapper code is added to the class (in in this case).
Note the style of inline documentation which can be extracted and placed on
the web. 

  class GvRasterLayer(GvLayer):
    def zoom_set(self,mag_mode,min_mode):
        """Set interpolation method

        I believe mag_mode sets the interpolation mode when zooming in past
        1:1 on a texture, and min_mode is the interpolation mode used for
        downsampling from the texture, but I am not sure.  Both default to
        bilinear, and are normally changed together.
        mag_mode -- One of gview.RL_FILTER_BILINEAR or gview.RL_FILTER_NEAREST.
        min_mode -- One of gview.RL_FILTER_BILINEAR or gview.RL_FILTER_NEAREST.
        return _gv.gv_raster_layer_zoom_set( self._o, mag_mode, min_mode )

A significant portion of C functions/methods cannot be automatically wrapped
like the above, so instead custom C code is written to wrap them.  This is
normally required in cases where pointers to basic data types are passed or
where it is desired to translate things into more natural Python data types
(like tuples or dictinoaries).  The following is an example of a simple 
C binding to expose a function to Python.  Note that a Python "method" style
wrapper is still generally required, like the other method. 

static PyObject *
_wrap_gv_layer_extents(PyObject *self, PyObject *args)
    PyObject *layer;
    GvRect rect;

    if (!PyArg_ParseTuple(args, "O!:gv_layer_extents", &PyGtk_Type, &layer))
        return NULL;
    gv_layer_extents(GV_LAYER(PyGtk_Get(layer)), &rect);
    return Py_BuildValue("(ffff)", rect.x, rect.y, rect.width, rect.height);
Frank's Course Outline
OpenEV Help