[SAGA-RG] python bindings

[Sylvain Reynaud]

Hi all,

Andre, I think you're right about the reason for the create() method ; 
it can indeed return a Task object that will contain the created object.

Mark, FYI you can configure JSAGA's "local://" adaptor to be mapped to 
URL scheme "fork://"... but anyway, there are many other differences 
between URL of various SAGA implementations (independently of the 
implemented binding). The other main difference between SAGA 
implementations is between the security contexts.
So if you want to develop an application that uses several SAGA 
implementations, creating URLs and security contexts will require 
implementation-specific code anyway.

Best regards,
Sylvain


Le 02/09/2011 06:55, Andre Merzky a écrit :
> 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
>>
>
>