Hello Peter, hi all, Il giorno 23/set/08, alle ore 23:26, Peter Tršöger ha scritto: (on 1. I have nothing to add to what you resumed)
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.
uhm... ok...
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.
Yes, I agree with you. Let's keep the strings.
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.
Probably it was my fault to talk about namedtuple. This is an implementation-related (so basically off-topic) thing. I don't want to be too verbose here, but defining a namedtuple you define a class, so, in principle, you can use named tuples and be conformant with the present specs.
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.
Ok, nice. Bye, e.