Hi all, we had a small, but productive meeting in Chicago, and, as we hoped, converged on python bindings very close to what PySAGA specifies and implements. Attached is a first draft of a python binding document for which we would like to get feedback and comments. FWIW, the document lives in our redmine git repository, at http://redmine.ogf.org/projects/saga-wg/repository/revisions/master/show/doc... . Thanks, Andre. -- Nothing is really difficult...
Attached is a first draft of a python binding document for which we would like to get feedback and comments.
Author names are mixed up - some on left and some on right Status: As SAGA -> As a SAGA so-far -> currently defined Copyright notice 2007-2010 -> 2012 2 SAGA Python Bindings last para. I don't think you should refer to these as class prototypes as the notion is not part of python. Instead just say: The explicit python bindings are listed in Appendix A. 2.1 Para 1 sentence 2 -> While we expect that language bindings will, in general, follow that hierarchy for Python it is not useful to do so. Omit 2.1 para 3 2.1.1 CAN -> MAY 2.1.2 Omit last two sentences 2.1.2 wrong kind of opening quote before "namespace" - this appears elsewhere too - a global edit with a regexp should find them 2.2 as lightly -> a slightly 2.2 add to text before bullet points: "they" 2.2 The reference for Python naming conventions is: http://www.python.org/dev/peps/pep-0008 2.4 -> The SAGA API includes a number of enums, which are usually related to classes within a specifi c API package. Python does not have a native notion of enums. We follow the recommendation in pep-0008 to define constants on a module level, written in all capital letters with underscores separating words. 2.5 Omit this section - it will be hard to get right and will just cause confusion 4.4 2007 -> 2012 Appendix A - This should start with an explananation of how to interpret what follows I will send comments on the contents of Appendix A as a separate email Steve
Thanks for the comments, Steve, appreciated. I'll work those in. About Appendix A: I got some comments from Ole, which I'll am currently applying -- I'll circulate an update ASAP. Best, Andre. On Wed, Oct 24, 2012 at 8:29 AM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
Attached is a first draft of a python binding document for which we would like to get feedback and comments.
Author names are mixed up - some on left and some on right
Status: As SAGA -> As a SAGA so-far -> currently defined
Copyright notice 2007-2010 -> 2012
2 SAGA Python Bindings last para. I don't think you should refer to these as class prototypes as the notion is not part of python. Instead just say: The explicit python bindings are listed in Appendix A.
2.1 Para 1 sentence 2 -> While we expect that language bindings will, in general, follow that hierarchy for Python it is not useful to do so.
Omit 2.1 para 3
2.1.1 CAN -> MAY
2.1.2 Omit last two sentences
2.1.2 wrong kind of opening quote before "namespace" - this appears elsewhere too - a global edit with a regexp should find them
2.2 as lightly -> a slightly
2.2 add to text before bullet points: "they"
2.2 The reference for Python naming conventions is: http://www.python.org/dev/peps/pep-0008
2.4 -> The SAGA API includes a number of enums, which are usually related to classes within a specifi c API package. Python does not have a native notion of enums. We follow the recommendation in pep-0008 to define constants on a module level, written in all capital letters with underscores separating words.
2.5 Omit this section - it will be hard to get right and will just cause confusion
4.4 2007 -> 2012
Appendix A - This should start with an explananation of how to interpret what follows
I will send comments on the contents of Appendix A as a separate email
Steve
-- Nothing is really difficult...
On Wed, Oct 24, 2012 at 9:34 AM, Andre Merzky <andre@merzky.net> wrote:
Thanks for the comments, Steve, appreciated. I'll work those in.
About Appendix A: I got some comments from Ole, which I'll am currently applying -- I'll circulate an update ASAP.
Attached. BTW: you (all) should create redmine accounts at redmine.ogf.org, add an ssh key to your account, join the saga-wg project, and then can start editing the document yourself :-) Cheers, Andre.
Best, Andre.
On Wed, Oct 24, 2012 at 8:29 AM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
Attached is a first draft of a python binding document for which we would like to get feedback and comments.
Author names are mixed up - some on left and some on right
Status: As SAGA -> As a SAGA so-far -> currently defined
Copyright notice 2007-2010 -> 2012
2 SAGA Python Bindings last para. I don't think you should refer to these as class prototypes as the notion is not part of python. Instead just say: The explicit python bindings are listed in Appendix A.
2.1 Para 1 sentence 2 -> While we expect that language bindings will, in general, follow that hierarchy for Python it is not useful to do so.
Omit 2.1 para 3
2.1.1 CAN -> MAY
2.1.2 Omit last two sentences
2.1.2 wrong kind of opening quote before "namespace" - this appears elsewhere too - a global edit with a regexp should find them
2.2 as lightly -> a slightly
2.2 add to text before bullet points: "they"
2.2 The reference for Python naming conventions is: http://www.python.org/dev/peps/pep-0008
2.4 -> The SAGA API includes a number of enums, which are usually related to classes within a specifi c API package. Python does not have a native notion of enums. We follow the recommendation in pep-0008 to define constants on a module level, written in all capital letters with underscores separating words.
2.5 Omit this section - it will be hard to get right and will just cause confusion
4.4 2007 -> 2012
Appendix A - This should start with an explananation of how to interpret what follows
I will send comments on the contents of Appendix A as a separate email
Steve
-- Nothing is really difficult...
-- Nothing is really difficult...
Hi Andre, Some additional followup from our earlier discussion today: 1. the first paragraph in 2.1is vague. also "functional" is not defined. whats the rationale for the difference? 2. package/class names of logical_file (in gfd.90) is called replica here. why? 3. what should it be then? 4. file and directory are in package "filesystem" which is not in gfd.90 either. Gr, Mark ________________________________ AMC Disclaimer : http://www.amc.nl/disclaimer ________________________________
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...
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']}) 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. 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
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...
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...
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...
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...
Hi Ole, I think this is the last open item I have from your mails: On Tue, Nov 13, 2012 at 4:25 PM, Ole Weidner <ole.weidner@rutgers.edu> wrote:
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?
I actually think you are right - but I am not sure we miss something. I'll go through those calls again one by one and will check. Best, Andre.
- 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...
-- Nothing is really difficult...
Hi Ole, On Fri, Dec 14, 2012 at 12:47 AM, Andre Merzky <andre@merzky.net> wrote:
Hi Ole,
I think this is the last open item I have from your mails:
On Tue, Nov 13, 2012 at 4:25 PM, Ole Weidner <ole.weidner@rutgers.edu> wrote:
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?
I actually think you are right - but I am not sure we miss something. I'll go through those calls again one by one and will check.
Problem is this: at the moment we have: entry.copy_self (tgt) dir .copy_self (tgt) dir .copy (src, tgt) And you propose I think to replace this with: entry.copy (tgt) dir .copy (src=None, tgt) but dir inherits from entry, and you can't overload on different signatures in python - so that would be invalid. The alternative would be to replace with: entry.copy (src=None, tgt) dir .copy (src=None, tgt) and to allways throw if a src is specified on an entry (which is not a dir) -- but that is (a) ugly, and (b) tedious to implement. Makes sense? Any better idea? Thanks, Andre.
- 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...
-- Nothing is really difficult...
-- Nothing is really difficult...
Hi Andre, I don't think I can agree with section 1.2 "Security Considerations". It reads: "A SAGA implementation is considered secure if and only if it fully supports (i.e. implements) the security models of the middleware layers it builds upon, and neither provides any (intentional or unintentional) means to by-pass these security models, nor weakens these security models’ policies in any way." Implementing the SAGA 'security models' (i.e., saga contexts and maybe permissions?) doesn't make an implementation 'secure'. 'Secure' is a very strong (and overloaded!) term and should really be avoided altogether. Best, Ole On Dec 13, 2012, at 18:49 , Andre Merzky <andre@merzky.net> wrote:
Hi Steve, all,
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
This would be now -- pdf is attached. Thanks!
Cheers, Andre.
-- Nothing is really difficult... <saga_bindings_python.pdf>-- saga-rg mailing list saga-rg@ogf.org https://www.ogf.org/mailman/listinfo/saga-rg
This text appears in most saga documents. I see it only as a definition of what we mean by secure. It does not mean much but is harmless. Sorry for the delay in responding last week - some things cropped up! Steve On 16 Dec 2012 08:30, "Ole Weidner" <ole.weidner@rutgers.edu> wrote:
Hi Andre,
I don't think I can agree with section 1.2 "Security Considerations". It reads:
"A SAGA implementation is considered secure if and only if it fully supports (i.e. implements) the security models of the middleware layers it builds upon, and neither provides any (intentional or unintentional) means to by-pass these security models, nor weakens these security models’ policies in any way."
Implementing the SAGA 'security models' (i.e., saga contexts and maybe permissions?) doesn't make an implementation 'secure'. 'Secure' is a very strong (and overloaded!) term and should really be avoided altogether.
Best, Ole
On Dec 13, 2012, at 18:49 , Andre Merzky <andre@merzky.net> wrote:
Hi Steve, all,
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
This would be now -- pdf is attached. Thanks!
Cheers, Andre.
-- Nothing is really difficult... <saga_bindings_python.pdf>-- saga-rg mailing list saga-rg@ogf.org https://www.ogf.org/mailman/listinfo/saga-rg
Hi Steve, On Wed, Oct 24, 2012 at 8:29 AM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
2.1 Para 1 sentence 2 -> While we expect that language bindings will, in general, follow that hierarchy for Python it is not useful to do so.
I would argue that usefulness is something to be evaluated by the implementor. I, for one, find inheritance exceedingly useful, also in python ;-)
Omit 2.1 para 3
That is supposed to lead into 2.1.x, so needs at least some replacement.
2.1.1 CAN -> MAY
Hmm, first you state quite strongly that inheritance is not useful, then you discourage the flattening option -- that does not fit? MAY means that this choice needs to be well motivated beyond the arguments in this document (kind of). Fine with me actually, but I think that is not consistent.
2.1.2 Omit last two sentences
The last sentence is repetition, removed - but the sentence before is relevant, no?
2.5 Omit this section - it will be hard to get right and will just cause confusion
I can see that - ok to add is as second appendix?
Appendix A - This should start with an explananation of how to interpret what follows
Makes sense. Thanks, Andre.
I will send comments on the contents of Appendix A as a separate email
Steve
-- Nothing is really difficult...
I have finally got back to this after a long period of doing other things On 24 October 2012 16:08, Andre Merzky <andre@merzky.net> wrote:
Hi Steve,
On Wed, Oct 24, 2012 at 8:29 AM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
2.1 Para 1 sentence 2 -> While we expect that language bindings will, in general, follow that hierarchy for Python it is not useful to do so.
I would argue that usefulness is something to be evaluated by the implementor. I, for one, find inheritance exceedingly useful, also in python ;-)
I had meant to shorten and simplify your sentence without changing its meaning. However I had shortened it too much. How about replacing the whole para with: The SAGA API defines an interface and class hierarchy which we normally expect language bindings to follow. In the case of Python some deviation produces a better result.
Omit 2.1 para 3
That is supposed to lead into 2.1.x, so needs at least some replacement.
I don't think it contains any essential linking material. If you wish to keep it then improve the grammar and don't mention duck-typing.
2.1.1 CAN -> MAY
Hmm, first you state quite strongly that inheritance is not useful, then you discourage the flattening option -- that does not fit? MAY means that this choice needs to be well motivated beyond the arguments in this document (kind of). Fine with me actually, but I think that is not consistent.
This is a misunderstanding. Inheritance is great - (except in C++ of course). You had the word CAN in caps which I presumed was meant to follow the rules of http://www.ietf.org/rfc/rfc2119.txt on the use of a few special words. I just suggested changing it to a standard word without changing the meaning.
2.1.2 Omit last two sentences
The last sentence is repetition, removed - but the sentence before is relevant, no?
It is not necessary and I see no need to introduce ducks
2.5 Omit this section - it will be hard to get right and will just cause confusion
I can see that - ok to add is as second appendix?
Try it - but my comments still stand!
Appendix A - This should start with an explananation of how to interpret what follows
Makes sense.
Thanks, Andre.
I will send comments on the contents of Appendix A as a separate email
Steve
-- Nothing is really difficult...
Hi Steve, On Tue, Oct 30, 2012 at 3:45 PM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
I have finally got back to this after a long period of doing other things
On 24 October 2012 16:08, Andre Merzky <andre@merzky.net> wrote:
Hi Steve,
On Wed, Oct 24, 2012 at 8:29 AM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
2.1 Para 1 sentence 2 -> While we expect that language bindings will, in general, follow that hierarchy for Python it is not useful to do so.
I would argue that usefulness is something to be evaluated by the implementor. I, for one, find inheritance exceedingly useful, also in python ;-)
I had meant to shorten and simplify your sentence without changing its meaning. However I had shortened it too much. How about replacing the whole para with:
The SAGA API defines an interface and class hierarchy which we normally expect language bindings to follow. In the case of Python some deviation produces a better result.
Ah, I see - thanks for clarifying! Yes, possibly that version - although I am not exactly against verbose text in specs (as you may have noticed ;-)
Omit 2.1 para 3
That is supposed to lead into 2.1.x, so needs at least some replacement.
I don't think it contains any essential linking material. If you wish to keep it then improve the grammar and don't mention duck-typing.
+1 on the grammar obviously. But why not referencing duck-typing? Isn't that the main reason why an implementor can completely ignore object hierarchy?
2.1.1 CAN -> MAY
Hmm, first you state quite strongly that inheritance is not useful, then you discourage the flattening option -- that does not fit? MAY means that this choice needs to be well motivated beyond the arguments in this document (kind of). Fine with me actually, but I think that is not consistent.
This is a misunderstanding. Inheritance is great - (except in C++ of course). You had the word CAN in caps which I presumed was meant to follow the rules of http://www.ietf.org/rfc/rfc2119.txt on the use of a few special words. I just suggested changing it to a standard word without changing the meaning.
got it, thanks.
2.1.2 Omit last two sentences
The last sentence is repetition, removed - but the sentence before is relevant, no?
It is not necessary and I see no need to introduce ducks
:-)
2.5 Omit this section - it will be hard to get right and will just cause confusion
I can see that - ok to add is as second appendix?
Try it - but my comments still stand!
Ok, I'll give it a try. Thanks again, Andre.
Appendix A - This should start with an explananation of how to interpret what follows
Makes sense.
Thanks, Andre.
I will send comments on the contents of Appendix A as a separate email
Steve
-- Nothing is really difficult...
-- Nothing is really difficult...
participants (4)
-
Andre Merzky -
M.A. Santcroos -
Ole Weidner -
Steve Fisher