[SAGA-RG] python bindings

[Andre Merzky]

Hi Mark, all,

On Thu, Sep 1, 2011 at 10:48 PM, M.A. Santcroos
<m.a.santcroos at amc.uva.nl> wrote:
> Dear all,
>
> Andre asked me to provide some more detailed information prior to the
> meeting in Lyon, so here goes.

Many thanks for the effort!  Inlined are some comments and questions...

Best, Andre.


> 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.
>
> [...]
>
> The VU bindings have create() calls for explicit constructors (not sure
> why).

Could the reason be to allow for asynchronous object construction?


> Both implementations make extensive use of getters and setters which are
> discouraged in Python.

The SAGA spec requires that some objects, such as job description, do not allow
free attributes (like 'my_jobclass = super'), and also restricts values several
attributes can have.  Is that mappable to a python hashtable (dictoinary)?  If
not, I would think that is the reason for setters and getters?



> 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 URL semantics should not be part of the language binding - for
good or for worse, that is an implementation detail....


> 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.

My $0.02:

  - quickly (re-)agree on a common binding, whatever that is
  - provide a thin wrapper around the C++ bindings, to be able
    to maintain both for a time
  - change the VU bindings to adhere to the agreement
  - provide a common test suite for both (something along
    the lines of Sylvain's interop tests)


> 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.

Yes, many thanks!

Steven, Sylvain, others - any input before we start bashing
our heads in Lyon? :)

Cheers, Andre.


> Regards,
>
> Mark
>
>
> 1. http://apidoc.saga.cct.lsu.edu/saga-python/latest/
> 2. http://apidoc.saga.cct.lsu.edu/saga-python-alt/
>
>
> --
>  saga-rg mailing list
>  saga-rg at ogf.org
>  http://www.ogf.org/mailman/listinfo/saga-rg
>



-- 
Nothing is ever easy...