Martin Landa wrote:
> >> GRASS 7.0.svn (spearfish60):~ > python
> >> grass70/swig/python/examples/rasteraccess.py
> >> Raster Map Name? elevation.10m
> >> 0
> >> Traceback (most recent call last):
> >> File "grass70/swig/python/examples/rasteraccess.py", line 47, in <module>
> >> print rown, myrow[0:10]
> >> TypeError: 'int' object is unsubscriptable
> >>
> >> ?
> >
> > Rast_get_row() returns an integer; if you want to print the first 10
> > values, use inrast[0:10].
> >
> > A much older version of the SWIG interface assumed that a non-const
> > int/float/double pointer argument referred to a row buffer which was
> > filled in by the function, and would automatically allocate the buffer
> > and return it as the result. This failed for other cases, so the
> > feature was removed.
>
> right, anyway 'inrast' as a PySwigObject, not a list.
>
> Traceback (most recent call last):
> File "rasteraccess.py", line 47, in <module>
> print rown, inrast[0:10]
> TypeError: 'PySwigObject' object is unsubscriptable
Er, right.
Try:
import array
inrast = array.array('i')
inrast.extend([0] * gis.G_window_cols())
This is a good example of one of SWIG's main limitations. The only
thing it knows about Rast_allocate_buf() is that it returns a void*;
there's no way that it can generate a usable Python object from that
(it doesn't know the actual element type or the number of elements).
In general, it's easier to create objects in Python and pass them to C
than the other way around.
The only real solution is to code wrappers by hand; a C prototype
simply doesn't contain enough information to create a wrapper in
anything beyond the simplest cases.
--
Glynn Clements <
[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
