[SAGA-RG] python bindings

[M.A. Santcroos]

Dear all,

Andre asked me to provide some more detailed information prior to the
meeting in Lyon, so here goes.

Attached you will find two files, one of them is the python example from
the LSU Python bindings [1].
The other file is the diff that is needed to make the same simple example
run with JPySAGA, which implements the API as defined by VU for their
Pysaga implementation [2].

I also did a review of the comparison done in the past, and that still
seems to be valid. For reference I've also attached it.
The code diff and the snippet below gives some intuition of the
differences.

===============

File               
----
VU module:filesystem, class:File
LSU module:filesystem._filesystem,class:file

Job
---
VU module:job, class:Job
LSU module:job._job, class:job

JobDescription     
--------------
VU module:job, class:JobDescription
LSU module:job._job, class:description

JobService         
----------
VU module:job, class:JobService
LSU module:job._job, class:service


Exception
---------
VU module:error, class:SagaException
LSU module:saga, class:exception

==============

On overall we can summarize that the LSU bindings have C++ style names and
the VU bindings have Python style names.
The VU bindings have create() calls for explicit constructors (not sure
why).
Both implementations make extensive use of getters and setters which are
discouraged in Python.
The VU package structure seems to be closer to the spec.
The LSU bindings use "fork://" for localhost execution and the VU bindings
use "local://".
The VU bindings need RMs to be of type URL only, LSU accepts strings too.

To conclude, the list of little differences continues for ever. See the
file vulsudiff.txt for an extensive overview.

Ideally, the bindings should become Python-like:
- CamelCase for classes
- lowercase_underscores for members
- No getters and setters
- No explicit create() constructors

Given this list, neither of the two implementations apply to these
requirements as is.

How to go forward? Functionally they don't seem to differ much, so that's
not a deal breaker.

The LSU bindings have most probably a larger user community, that could be
an argument in favor of LSU.
Another option would be that we could go out and define a third set of
bindings with the best elements of both implementations, not sure if that
would just make the situation worse.

I hope this gives some structure to the discussion.

Regards,

Mark


1. http://apidoc.saga.cct.lsu.edu/saga-python/latest/
2. http://apidoc.saga.cct.lsu.edu/saga-python-alt/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: example_lsu-python.py
Type: text/x-python-script
Size: 645 bytes
Desc: example_lsu-python.py
Url : http://www.ogf.org/pipermail/saga-rg/attachments/20110901/bbdba267/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-example.diff
Type: application/octet-stream
Size: 945 bytes
Desc: python-example.diff
Url : http://www.ogf.org/pipermail/saga-rg/attachments/20110901/bbdba267/attachment-0001.obj 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vulsudiff.txt
Url: http://www.ogf.org/pipermail/saga-rg/attachments/20110901/bbdba267/attachment-0001.txt