[GRASS-user] Re: CYGWIN

[Glynn Clements]

Luigi Ponti wrote:

> > There is no grass.py. It existed for a brief time, but the "grass"
> > module was replaced with a "grass" package containing multiple
> > modules, then later split into two subpackages, "script" and "lib".
> >   
> The package is described in the programming manual -- I should have 
> explored better:
> http://download.osgeo.org/grass/grass6_progman/pythonlib.html
> 
> The progman page above says that the code is in lib/python/ while in my 
> osgeo4w GRASS 6.4.0svn r36506
> http://trac.osgeo.org/osgeo4w/wiki/pkg-grass
> 
> the code seems to reside into etc/python.

The code is in lib/python in the source tree; it gets installed into
$GISBASE/etc/python. The startup scripts add $GISBASE/etc/python to
PYTHONPATH, so "import grass.script" etc should work for any Python
script run from within a GRASS session.

> > The change was made to accomodate the SWIG bindings for the GRASS
> > libraries in the "grass.lib" package, so the scripting functions were
> > moved from "grass" to "grass.script".
> 
> Would the lib subpackage you mentioned be any useful in developing GRASS 
> scripts? (I could not find it in my osgeo4w installation.)

The grass.lib package contains bindings for the functions in the main
GRASS libraries. The bindings are generated automatically from the
header files using SWIG; not all of them are usable.

grass.lib allows you to call GRASS library functions from Python,
while grass.script is designed for running GRASS commands.

Programming at the library level is harder, almost completely
untested, and more likely to change from one version to the next.

Also, Python isn't exactly a fast language; processing maps in Python
will typically be much slower than in C (and probably not
significantly simpler, as the Python bindings are just bindings; you
still have to e.g. allocate and free buffers explicitly).

-- 
Glynn Clements <glynn at gclements.plus.com>