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

Hi Enrico, I added the list as CC, maybe somebody has an opinion. 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()

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

I don't know. Opinions please. Is there any additional reason for a Session object, beside the internal list of jobs ? 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:

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

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. library wrapper is minimal. I will change that. /Peter.