Hi Paul, Quoting [PFA van Zoolingen] (Aug 12 2008):
I think we should go a step further and add Python like interfaces to types as saga.attribute. saga.attribute is essentially a dictionary, and I would like to see the possibility to work with attributes the same way.
I.e.
m = saga.metric(...) attr = saga.attribute(m) print attr["type"] # print the type of the metric
or even:
print m["type"]
saga.monitoring.Metric() implements (or is a subclass of) saga.attributes.Attributes() in Python so metric should have all methods inherited from Attributes. It should be doable to store the attributes in a dictionary and make that easily accessible -> m.dict["type"] The inherited methods should then operate on the dictionary. m.list_attributes and m.find_attributes could return (a subset or the complete) dictionary
Yes, agree: the native dictionary interface should be exposed for classes which have attributes.
Sync, Async, Task
That is certainly an option. Just to give you some trouble, here are some others:
len_out = f.read (len, buffer, sync); # thats your version task = f.read (len, buffer, task);
This one is also my version. In Python you can let the copy method return a task object or the integer. It's not bound to one return type.
Sorry for being inprecise: I meant both lines being your version...
len_out = f.read_sync (len, buffer); task = f.read_task (len, buffer);
len_out = f.read (sync, len, buffer); task = f.read (task, len, buffer);
Thes could also be my version if you explicitly named the parameters and did: f.read( type=sync, len=len, buffer=buffer)
Ah, I see - sorry, wasn't aware of the explicit parameter naming thing in python. Cute :-)
len_out = sync_f.read (len, buffer); task = task_f.read (len, buffer);
And there are more... All options have pro and cons. We had that discussion for a long time as we designed the task model. If you are interested in gazillions of mails running circles, I can dig them out of the archive ;-)
Do you happen to know on which mailinglist and the name of the discussion? Then I will certainly check them.
Your model is nice, as it is simple. The only drawback are optional arguments:
dir.copy (src, target, Overwrite, sync);
What happens without flags, e.g. no Overwrite is wanted:
dir.copy (src, target, 0, sync);
Basically, you cannot have default args anymore, and always have to specify all arguments. Thats tedious to the programmer.
The defaults are specified in the method, example: def copy (src, target, flags=none, type=sync)
When you call the method, Python fills in the blanks. Thats also why the default parameters are at the back of the parameter list. If you want to leave out the flags parameter but want to specifiy type: dir.copy (src, target, type=async)
nice
Python will accept dir.copy(src, target, type) but then uses type as the flags parameter, which (should!) result in errors.
No idea if python provides some clever way to solve this - most other languages don't. Thus, please do also consider to put the flag in the first place, or to use some other qualifiers (method name, etc). Can't recall at the moment what way Hartmut chose in his Python implementation, sorry.
If it is an optional parameter with a default specified, it has to go in the back of the parameter list. I don't know if this clarifies some issues for you?
Yes, it does, thanks. Cheers, Andre. -- Nothing is ever easy.