Quoting [Hartmut Kaiser] (Aug 13 2008):
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.
I think I also saw somthing resembling a flag in Hartmuts Python wrapper apidoc, although I can't find it anymore. ('service' parameter?)
We have it the other way around, currently. It's the first parameter, and we have two different overloads, i.e.:
f.read(buffer, len) f.read(saga.task.Sync, buffer, len) f.read(saga.task.ASync, buffer, len) f.read(saga.task.Task, buffer, len)
but I agree that the usage of named parameters is better suited for Python and I'm ready to change this detail. This will move the method type to be the last parameter for all of the API functions:
f.read(buffer, len, type=saga.task.Sync)
but we need to add a 4th method type saga.task.Plain to distinguish between
bytes_read = f.read(buffer, len) and task = f.read(buffer, len, type=saga.task.Sync)
I take that Plain would be the default then, and, also by default, not be visible? Thus you'd have: bytes_read = f.read (buffer, len) bytes_read = f.read (buffer, len, type=saga.task.Plain) task = f.read (buffer, len, type=saga.task.Sync) task = f.read (buffer, len, type=saga.task.Async) task = f.read (buffer, len, type=saga.task.Task) with the first two being the same call (once with default parameter, once explicit)? Thanks, Andre.
But since we have a big release (V1.0) for our SAGA package planned for September, I'll probably address all these changes after that only. Currently all users of the Python bindings are using the plain API only, so nothing should change for them.
Regards Hartmut
-- Nothing is ever easy.