[GRASS-dev] Python Scripting

[Michael Barton]

On Jul 21, 2008, at 7:52 AM, Dan D'Alimonte wrote:

> Having never used SWIG, my understanding was it gives you access to  
> the functions in the C library? This is a good thing, yes, but I was  
> thinking of something beyond this. As I stated earlier, to allow  
> programming for GRASS at a higher level the the C functions,  
> including making use of Python's Object Oriented features to  
> encapsulate GRASS data structures and processes. For example, a  
> RasterLayer class that contains raster data, with it associated  
> spatial characteristics, that can provide interators over rows of  
> cells, columns of cells, individual cells, or moving windows such as  
> a 3x3 matrix.

My understanding is that the Python GRASS SWIG interface makes this  
possible. However, wrapping this into a nice Python library would make  
it more accessible to a broader audience.

> And apologies in return if I've been unclear.

Probably my lack of understanding of the more advanced aspects of  
Python.

Michael

>
>
>
> Michael Barton wrote:
>> I can see how it could be handy to be able to access GRASS library  
>> functions from Python. Would this differ from the Python SWIG  
>> interface? I thought that SWIG was supposed to allow this?
>> Or maybe I misunderstand. Sorry if I am missing something.
>> Michael
>> On Jul 18, 2008, at 3:29 PM, Dan D'Alimonte wrote:
>>> That's why I put it to the mailing list. I was picturing something  
>>> that acted as an intermediate between the low-level, direct data  
>>> access nature of the C library and the high-level nature of shell  
>>> scripts, This could possibly easily allow access to both in the  
>>> same program. In situations where shell scripts' limits make you  
>>> jump through hoops and the C library is just too low-level, a  
>>> solid Python library would be of use in developing GRASS programs.  
>>> It could also allow for more people access to GRASS and GIS  
>>> programming by providing a language with a much lower learning  
>>> curve then C.
>>>
>>> As to whether it is needed or worth undertaking, that would be up  
>>> to the community. What I put below was based on some periodic  
>>> thoughts I've had in the past, but an actual design and  
>>> implementation would need to be developed if there is enough  
>>> interest. And if Python is indeed the right environment to do this  
>>> in (I know speed of raster processing has already been brought up).
>>>
>>> -- Dan.
>