[DRMAA-WG] OGF DRMAA Python Binding - First Draft

[Peter Tršöger]

Hi Enrico,

I added the list as CC, maybe somebody has an opinion.
> 1. Session class (this is something I thought about when reading the 
> java specs also): to me, in python it seems useless. How about moving 
> the class methods at the module level? The class instances don't seem 
> to have any state, so...
Your idea caused me a lot more thinking than expected. The DRMAA IDL 
specification explicitly defines the Session interface, since the 
document was created based on the Java / C# world, where everything is 
encapsulated in a class. DRMAA for C has no classes at all. And now 
comes Python, some kind of C / OO hybrid. In fact you are right - an 
implementation has no real need for the Session class. But this is only 
true since multiple parallel or nested sessions are explicitly 
forbidden. The list of jobs running in the session can therefore be part 
of the module state.

We can now choose to make it look like all the other DRMAA OO bindings, 
or we can ignore that and do it very 'Pythonic'. In the former case, it 
is ugly Python. In the latter case, it is ugly OO DRMAA. I would prefer 
ugly Python (think of MiniDom), but this:

 >>> import drmaa
 >>> drmaa.init()

is simply easier than this:

 >>> import drmaa
 >>> s=drmaa.Session()
 >>> s.init()

I don't know. Opinions please. Is there any additional reason for a 
Session object, beside the internal list of jobs ?
> 2. (not really very important, however...) exceptions: I don't like 
> very much the names (don't seem to be in line with the python standards)
We want to keep some cross-language readability of DRMAA code, so the 
names should stay as they are.
> 3. job templates startTime and endTime: these imo should be datetime 
> instances, not strings
I would *love* to do that, but DRMAA has this historical concept of a 
partial time stamp. It basically allows you to express incomplete time 
information ("run the job next Monday"). Check the IDL spec for a longer 
explanation. Partial time stamps prevent us from using normal date 
types. I added an according sentence to the rationale section.
> 4. value objects: these are really immutable collections of key/value 
> pairs. For these tasks, a new type is going to be introduced, named 
> "namedtuple", that behaves like a tuple (i.e. is iterable, immutable, 
> hashable, ...) buy having entries also accessible by names. The docs 
> are here: 
> http://docs.python.org/dev/library/collections.html#collections.namedtuple and 
> it's very possible to backport its behaviour for previous versions of 
> python (a few tens of python which would be used if the namedtuple 
> module is not available). Also, some other valueobjects (e.g. Version) 
> would be easily implemented with namedtuples.
This all looks quite new and "beta" like, even though the discussions 
around structure-like sequences are pretty old:

http://mail.python.org/pipermail/python-dev/2002-November/030361.html

The OMG IDL Python binding also maps "valuetype" to class, so I would 
like to stick with that. Using Python 2.6 features would be a general 
design decision - think of abstract base classes support. I avoided that 
in favour of an "old-style" Python interface. We can still fight about that.
> 5. many integer values are directly derived from the C api, e.g.
> I'd change these to their string equivalent. Strings are easies to 
> log, save, and, more importantly, read when using the interpreted 
> while you are debugging
> e.g. SUSPEND -> "suspend", RESUME -> "resume" etc etc
Ok, this makes sense for Python, and the implementation overhead for a C 
library wrapper is minimal. I will change that.

/Peter.