Hi Andre, the document says: "The constructor has switched the session and name parameters, each method has a tasktype parameter because NSEntry and NSDirectory subclass Async and a number of methods have a _self suffix added to the method name. The reason of the added suffixes is that NSEntry and NSDirectory have a number of identical methods, but with slightly different meaning. Because overloading is not available and intergrating both methods into one method would result in complicated and user unfriendly implementations, the method names were changed." I am not sure if I agree with that statement. I'm not quite sure why instead of having two individual methods, one of which is not even in GFD.90: is_dir_self (self, tasktype=TaskType.NORMAL) is_dir(self, name, tasktype=TaskType.NORMAL) we can't just implemented it as: is_dir (self, path=None, tasktype=TaskType.NORMAL) path=None would imply '_self'. I think this would be perfectly intuitive and would better 'map' to the unfortunately overloaded methods defined in GFD.90. Also, 'dynamic typing' is of course considered the preferred idiom to emulate method overloading in Python, which shouldn't really surprise you :P Thoughts? - Ole On Nov 12, 2012, at 15:51 , Andre Merzky <andre@merzky.net> wrote:
They are awefull all right, but I don't see a better way. Please have a look at the the repository -- under pysaga/doc/ you'll see masterthesis-paul.pdf which motivates that decision quite nicely. You probably should go over that doc anyway.
Best, Andre.
On Mon, Nov 12, 2012 at 8:43 PM, Ole Weidner <ole.weidner@rutgers.edu> wrote:
Hi Andre,
can you please lay out the arguments for the existence of these abominable is_dir_self, is_link_self, etc. constructs? (With some example code, if possible). They look beyond awful and are, btw. a violation of GFD.90 ;-) Let's see if we can come up with something better!
Thanks! Ole
On Nov 12, 2012, at 14:33 , Andre Merzky <andre@merzky.net> wrote:
Hi Ole,
On Mon, Nov 12, 2012 at 7:40 PM, Ole Weidner <ole.weidner@rutgers.edu> wrote:
Hi Andre, All
I was just thinking through some practical / convenient improvements for the Python Language bindings. Do you think it would make sense to allow creation of a saga.job.Description from a dictionary, e.g.,
jd = saga.job.Description({'Executable':'/bin/sleep', 'Arguments':['60']})
I should have added that in the bindings - the implementation allows that already. Thanks!
IMHO this would be a very nice, optional addition. In conjunction with the already existing attributes_as_dict(), the API would become more 'symmetric' and would allow not only serialization but also convenient de-serialization.
Also, *please* rename attributes_as_dict() to as_dict(). The attribute_ prefix is redundant (Attributes.attributes_as_dict()) and as_dict() is just more commonly used.
Makes sense.
Best, Andre.
Cheers, Ole
On Nov 9, 2012, at 20:32 , Andre Merzky <andre@merzky.net> wrote:
Yes, sure! I am still working on the parameter types/names/documentation, and will send it around as soon as that is done.
The sources are as always in the redmine git.
Best, Andre.
On Fri, Nov 9, 2012 at 8:23 PM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
Andre, Will you circulate a new PDF when you want us to read it again? Steve
-- Nothing is really difficult... -- saga-rg mailing list saga-rg@ogf.org https://www.ogf.org/mailman/listinfo/saga-rg
-- Nothing is really difficult...
-- Nothing is really difficult...