Open Grid Forum


Community Practice

Archived Comments



OGF Public Comments

Public comments are a very important part of the OGF document approval process.  Through public comments, documents are given scrutiny by people with a wide range of expertise and interests. Ideally, a OGF document will be self-contained, relying only on the other documents and standards it cites to be clear and useful.  Public comments of any type are welcomed, from small editorial comments to broader comments about the scope or merit of the proposed document.  The simple act of reading a document and providing a public comment that you read it and found it suitable for publication is very useful, and provides valuable feedback to the document authors.

Thank you for making public comments on this document!

Comments for Document: Distributed Resource Management Application API 1.0 - Python Language Binding
Author(s):P. Tröger, M. Löwis, E. Sirola
Public Comment End:30 Nov, 2008

To make anonymous comments, please use 'anonymous' and 'guest' as the un/pw.


Posted by: p_v_zoolingen 2008-11-05 07:32:09Misc Comments on Python Language Binding

I am currently specifying a Python Language Binding for SAGA (GFD-R-P.90) and implementing that language binding for the Java Reference implementation of SAGA and have some comments. I hope they are useful for you.

1) Since Python does not have enums, its hard to implement them in a similar data structure. But instead of putting all the variables in namespace (Job control action, Job state and Job submission state) it might be better to put these 3 groups in a separate class, since the are related variables (the reason they were first put into a enum)

class JobSubmissionState(object):
HOLD_STATE = 'hold'
ACTIVE_STATE = 'active'

2) Session.init(). If it is not mapped to Session.__init__(), why call it the same and create possible confusion. initialize() or attach() might be better names.

3) Do you have default parameter values for the methods? For instance, Session has TIMEOUT_NO_WAIT and TIMEOUT_WAIT_FOREVER but is one of them the default value? if NO_WAIT is the default you could have:
def synchronize(self, jobList, dispose, timeout = self.TIMOUT_NO_WAIT)

and want to synchronize with no wait, you could call synchronize(JobList, Dispose)

or def wait(jobName, timeout = self.TIMEOUT_NOT_WAIT) and could do wait("some job")

4) Do you want parameters for __init__? Like def __init__(self, contact="", drmsInfo="", drmaImplementation="", version=Version() ) so you can set these parameters while constucting the Session object. Since they have default values, you can still call s = drmaa.Session()

5) Variables like etc, can be changed, since variables cannot be write protected or anything. (except making it really hard with the double underscore mechanism). Should the changes be instantly propagated to the underlying implementation or are the variables only there as information to users, are changes to them ignored and can be changed only through getters/setters.

This can become a problem if the python binding is implemented as a wrapper, and wraps around an object which does not notice changes made in the wrapper, but could notice them when changing the variable through a set() method

Hope the comments help,
Paul van Zoolingen,
Master Student Computer Science, Vrije Universiteit, Amsterdam, The Netherlands

Posted by: kielmann 2008-11-05 07:58:05
This document is prescribing the syntax of DRMAA1.0 in the Python language. As such, it is certainly more a document for the recommendation track rather than
a purely informational document. As such I would suggest to change gears accordingly.

I also would strongly ask the authors to back their document with some practical experience from implementing this language binding. At least, I would like to see a (kind of) comprehensive set of programming examples that show how the presented Python module would be used in an application program. Given my (painful) experience with designing the SAGA API, I am convinced that such a "reality check" of the language binding will uncover weak spots and/or cumbersome details that might need to be changed. Even stronger support for the language binding would be experience from a test implementation that checks how the interface could be implemented.

Posted by: szalik 2008-11-14 09:29:12Re: Misc Comments on Python Language Binding
Hi Paul,

In 5) you state that variables cannot we write protected. Actually, they can be -- there's such thing as 'property' in classes (

Please, do not use setters/getters in Python... It's so unpythonic! ;-)

> login   RSS RSS Contact Webmaster

OGFSM, Open Grid ForumSM, Grid ForumSM, and the OGF Logo are trademarks of OGF