[GRASS-dev] rasteraccess.py Python error

Hi,

I have made some necessary updates in
grass70/swig/python/examples/rasteraccess.py
but seem to have missed one:

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

?
Markus

Markus Neteler wrote:

I have made some necessary updates in
grass70/swig/python/examples/rasteraccess.py
but seem to have missed one:

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.

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

Hi,

2009/10/11 Glynn Clements <glynn@gclements.plus.com>:

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

Probably Rast_get_row could return list of values (or empty list on
error) in Python Swig interface...

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Martin wrote:

Probably Rast_get_row could return list of values (or empty
list on error) in Python Swig interface...

I don't know if it helps, but see also swig/python/NumPtr/

Hamish

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 <glynn@gclements.plus.com>