[SAGA-RG] SAGA Python language binding naming.

[Andre Merzky]

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.