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

[Enrico Sirola]

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.