[DRMAA-WG] OGF DRMAA Python Binding - First Draft
Enrico Sirola
enrico.sirola at gmail.com
Thu Sep 25 04:41:40 CDT 2008
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.
More information about the drmaa-wg
mailing list