[SAGA-RG] SAGA Python language binding naming.

[PFA van Zoolingen]

Andre, Hartmut,


You are right about the package names: Its better to leave them in. If a 
Python programmer does want to do it different, he can always do:
>>>import saga
>>>from saga import url
>>>from url import URL
>>>temp = URL()          # instead of saga.url.URL()


>Class names
>Exception names
>Enum types
>Function names
>Variable names

check

>> Return types:

> 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

I will try to compile a list of classes, their methods and return values.


>> 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.

>  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)
>
>  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)

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?

Hartmut, what do you have currently in your wrapper?


Greetings,
Paul van Zoolingen.