Re: [SAGA-RG] SAGA attributes as Python dictionaries?
On Wed, 2009-11-04 at 19:18 -0600, Hartmut Kaiser wrote:
On Wed, Nov 4, 2009 at 6:34 PM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
Just a note to remind people that the dictionary syntax in python is just a convenience - you need to implement __setitem__, __getitem__, __delitem__ etc. Our __setitem__ can reject requests to set fields whoch don't already exist for those cases where the set of attributes is not extensible. It just needs a private method called by the implementation to set the attributes with any defalt values and indicate whether or not it is extensible. I think it is best to try it and see if there are any practical problems. Also see: http://docs.python.org/library/userdict.html#module-UserDict which may be useful.
It is certainly doable from the technical point of view. My question is what would be the advantages of having a dict-like interface? Would that be in this form then:
If I rember the discussion from Banff correctly, the proposal was more like
jobDescription.attributes["Executable"] = "/bin/hostname"
Why not:
jobDescription["Executable"] = "/bin/hostname"
Yes, I'd also prefer this. Much shorter, and it resembles that a job description IS-A Attributes.
to decouple the attributes from the object properties. The dictionary seems to offer a reasonable interface for atributes, so why not use it?
not sure if one can then argue why not to use
jobDescription.attributes.Executable = "/bin/hostname"
Not good as we have no way to ensure only proper attributes are accessed. For instance
jobDescription.attributes.Executable1 = "/bin/hostname"
will go unnoticed as Python simply creates a member Executable1 assigning the string.
Ah, I did not know this! Hmm, that would indeed be a very good reason not to use Python properties for attributes.
One question about both approaches though, and to also about both approaches you list below: how would async ops be realized?
Async ops are separate and have to follow the get_attribute/set_attribute interface (which should be implemented in addition anyways)
... which gives more than one way to set/get attributes. I'm not sure what is more 'Pythonic': providing exactly one way to access attributes (i.e. via set_/get_attribute), or to provide a language-specific construct (dictionaries) as well. Technically, providing a dict interface as well seems entirely possible. It seems more a matter of taste whether to use them or not, especially since SAGA attributes are more restrictive than a normal dict. best, Mathijs
Quoting [Mathijs den Burger] (Nov 05 2009):
On Wed, 2009-11-04 at 19:18 -0600, Hartmut Kaiser wrote:
On Wed, Nov 4, 2009 at 6:34 PM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
Just a note to remind people that the dictionary syntax in python is just a convenience - you need to implement __setitem__, __getitem__, __delitem__ etc. Our __setitem__ can reject requests to set fields whoch don't already exist for those cases where the set of attributes is not extensible. It just needs a private method called by the implementation to set the attributes with any defalt values and indicate whether or not it is extensible. I think it is best to try it and see if there are any practical problems. Also see: http://docs.python.org/library/userdict.html#module-UserDict which may be useful.
It is certainly doable from the technical point of view. My question is what would be the advantages of having a dict-like interface? Would that be in this form then:
If I rember the discussion from Banff correctly, the proposal was more like
jobDescription.attributes["Executable"] = "/bin/hostname"
Why not:
jobDescription["Executable"] = "/bin/hostname"
Yes, I'd also prefer this. Much shorter, and it resembles that a job description IS-A Attributes.
So, how would async attrib setting work?
to decouple the attributes from the object properties. The dictionary seems to offer a reasonable interface for atributes, so why not use it?
not sure if one can then argue why not to use
jobDescription.attributes.Executable = "/bin/hostname"
Not good as we have no way to ensure only proper attributes are accessed. For instance
jobDescription.attributes.Executable1 = "/bin/hostname"
will go unnoticed as Python simply creates a member Executable1 assigning the string.
Well, I think the proposal is not to use the default dict implementation. Instead, the ine above would translate into a set_attribute on the Java or C++ backend, which would throw.
Ah, I did not know this! Hmm, that would indeed be a very good reason not to use Python properties for attributes.
One question about both approaches though, and to also about both approaches you list below: how would async ops be realized?
Async ops are separate and have to follow the get_attribute/set_attribute interface (which should be implemented in addition anyways)
... which gives more than one way to set/get attributes. I'm not sure what is more 'Pythonic': providing exactly one way to access attributes (i.e. via set_/get_attribute), or to provide a language-specific construct (dictionaries) as well.
Technically, providing a dict interface as well seems entirely possible. It seems more a matter of taste whether to use them or not, especially since SAGA attributes are more restrictive than a normal dict.
Ah, I see - so basically you propose to have set_attribute etc for async calls (and probably for sync, too, once they are there), and *additionally* have the dict interface. ok. Thanks, Andre. -- Nothing is ever easy.
On Thu, Nov 5, 2009 at 2:00 PM, Andre Merzky <andre@merzky.net> wrote:
Quoting [Mathijs den Burger] (Nov 05 2009):
On Wed, 2009-11-04 at 19:18 -0600, Hartmut Kaiser wrote:
On Wed, Nov 4, 2009 at 6:34 PM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
Just a note to remind people that the dictionary syntax in python is just a convenience - you need to implement __setitem__, __getitem__, __delitem__ etc. Our __setitem__ can reject requests to set fields whoch don't already exist for those cases where the set of attributes is not extensible. It just needs a private method called by the implementation to set the attributes with any defalt values and indicate whether or not it is extensible. I think it is best to try it and see if there are any practical problems. Also see: http://docs.python.org/library/userdict.html#module-UserDict which may be useful.
It is certainly doable from the technical point of view. My question is what would be the advantages of having a dict-like interface? Would that be in this form then:
If I rember the discussion from Banff correctly, the proposal was more like
jobDescription.attributes["Executable"] = "/bin/hostname"
Why not:
jobDescription["Executable"] = "/bin/hostname"
Yes, I'd also prefer this. Much shorter, and it resembles that a job description IS-A Attributes.
So, how would async attrib setting work?
to decouple the attributes from the object properties. The dictionary seems to offer a reasonable interface for atributes, so why not use it?
not sure if one can then argue why not to use
jobDescription.attributes.Executable = "/bin/hostname"
Not good as we have no way to ensure only proper attributes are accessed. For instance
jobDescription.attributes.Executable1 = "/bin/hostname"
will go unnoticed as Python simply creates a member Executable1 assigning the string.
Well, I think the proposal is not to use the default dict implementation. Instead, the ine above would translate into a set_attribute on the Java or C++ backend, which would throw.
Only in the case we provide a custom __setattr__() method for our jobDescription.attributes objects, this erratic assignment would be caught. Otherwise it will go unnoticed, as it won't translate to any invocation of the underlying layer.
Ah, I did not know this! Hmm, that would indeed be a very good reason not to use Python properties for attributes.
One question about both approaches though, and to also about both approaches you list below: how would async ops be realized?
Async ops are separate and have to follow the get_attribute/set_attribute interface (which should be implemented in addition anyways)
... which gives more than one way to set/get attributes. I'm not sure what is more 'Pythonic': providing exactly one way to access attributes (i.e. via set_/get_attribute), or to provide a language-specific construct (dictionaries) as well.
Technically, providing a dict interface as well seems entirely possible. It seems more a matter of taste whether to use them or not, especially since SAGA attributes are more restrictive than a normal dict.
Ah, I see - so basically you propose to have set_attribute etc for async calls (and probably for sync, too, once they are there), and *additionally* have the dict interface.
As said previously, having an additional way of doing the same thing is complicating rather than helping the user. The user will happily use the dict interface, but then notice that that is not possible anymore once he decided to have an asynchronous job. So he has to learn the "new" way anyway. Why not doing it in the first place and preventing later confusion? Cheers, -- /Manuel
Quoting [Manuel Franceschini] (Nov 05 2009):
As said previously, having an additional way of doing the same thing is complicating rather than helping the user. The user will happily use the dict interface, but then notice that that is not possible anymore once he decided to have an asynchronous job. So he has to learn the "new" way anyway. Why not doing it in the first place and preventing later confusion?
Sounds good to me. But maybe its time by now to come to a conclusion - I think I am reading the same arguments over and over again in the thread ;) So, there have been different proposals: A) description.executable = "/bin/date"; description.set_attribute ("Executable", "/bin/date"); B) description[executable] = "/bin/date"; description.set_attribute ("Executable", "/bin/date"); C) description.attributes.executable = "/bin/date"; description.set_attribute ("Executable", "/bin/date"); D) description.attributes["Executable"] = "/bin/date"; description.set_attribute ("Executable", "/bin/date"); E) description.set_attribute ("Executable", "/bin/date"); I think C and D did not catch on - just listed for completeness. Did I forget a version? So, I'd love to see a show of hands for the different versions - maybe we can cut the thread short. Thanks, Andre. -- Nothing is ever easy.
On Thu, 2009-11-05 at 20:12 +0100, Andre Merzky wrote:
Quoting [Manuel Franceschini] (Nov 05 2009):
As said previously, having an additional way of doing the same thing is complicating rather than helping the user. The user will happily use the dict interface, but then notice that that is not possible anymore once he decided to have an asynchronous job. So he has to learn the "new" way anyway. Why not doing it in the first place and preventing later confusion?
Sounds good to me.
+1
But maybe its time by now to come to a conclusion - I think I am reading the same arguments over and over again in the thread ;)
So, there have been different proposals:
A) description.executable = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
B) description[executable] = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
C) description.attributes.executable = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
D) description.attributes["Executable"] = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
E) description.set_attribute ("Executable", "/bin/date");
I think C and D did not catch on - just listed for completeness. Did I forget a version?
For completeness: how to express async and task versions. I assume that would look like: description.set_attribute("Executable", "/bin/date", TaskType.NORMAL)
So, I'd love to see a show of hands for the different versions - maybe we can cut the thread short.
I opt for E: one syntax for all cases is the simplest solution. best, Mathijs
Quoting [Mathijs den Burger] (Nov 06 2009):
But maybe its time by now to come to a conclusion - I think I am reading the same arguments over and over again in the thread ;)
So, there have been different proposals:
A) description.executable = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
B) description[executable] = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
C) description.attributes.executable = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
D) description.attributes["Executable"] = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
E) description.set_attribute ("Executable", "/bin/date");
+1, for the same reasons as Mathijs. A.
I think C and D did not catch on - just listed for completeness. Did I forget a version?
For completeness: how to express async and task versions. I assume that would look like:
description.set_attribute("Executable", "/bin/date", TaskType.NORMAL)
So, I'd love to see a show of hands for the different versions - maybe we can cut the thread short.
I opt for E: one syntax for all cases is the simplest solution.
best, Mathijs
-- Nothing is ever easy.
Though I like D, as it can't work when the extra parameter is needed for tasks, I agree that we should go for E. If someone comes up with a smart way of doing something else we can add it later. Steve 2009/11/6 Andre Merzky <andre@merzky.net>:
Quoting [Mathijs den Burger] (Nov 06 2009):
But maybe its time by now to come to a conclusion - I think I am reading the same arguments over and over again in the thread ;)
So, there have been different proposals:
A) description.executable = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
B) description[executable] = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
C) description.attributes.executable = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
D) description.attributes["Executable"] = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
E) description.set_attribute ("Executable", "/bin/date");
+1, for the same reasons as Mathijs.
A.
I think C and D did not catch on - just listed for completeness. Did I forget a version?
For completeness: how to express async and task versions. I assume that would look like:
description.set_attribute("Executable", "/bin/date", TaskType.NORMAL)
So, I'd love to see a show of hands for the different versions - maybe we can cut the thread short.
I opt for E: one syntax for all cases is the simplest solution.
best, Mathijs
-- Nothing is ever easy. -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
I think we have an agreement on E then: E) description.set_attribute ("Executable", "/bin/date"); So, no dict, no properties, but a simple plain SAGA attribute API. Great :-) Thanks, Andre. Quoting [Steve Fisher] (Nov 06 2009):
Date: Fri, 6 Nov 2009 13:37:28 +0000 Subject: Re: [SAGA-RG] SAGA attributes as Python dictionaries? From: Steve Fisher <dr.s.m.fisher@gmail.com> To: Andre Merzky <andre@merzky.net> Cc: Mathijs den Burger <mathijs@cs.vu.nl>, SAGA-RG <saga-rg@ogf.org>, hartmut.kaiser@gmail.com
Though I like D, as it can't work when the extra parameter is needed for tasks, I agree that we should go for E. If someone comes up with a smart way of doing something else we can add it later.
Steve
2009/11/6 Andre Merzky <andre@merzky.net>:
Quoting [Mathijs den Burger] (Nov 06 2009):
But maybe its time by now to come to a conclusion - I think I am reading the same arguments over and over again in the thread ;)
So, there have been different proposals:
A) description.executable = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
B) description[executable] = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
C) description.attributes.executable = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
D) description.attributes["Executable"] = "/bin/date"; description.set_attribute ("Executable", "/bin/date");
E) description.set_attribute ("Executable", "/bin/date");
+1, for the same reasons as Mathijs.
A.
I think C and D did not catch on - just listed for completeness. Did I forget a version?
For completeness: how to express async and task versions. I assume that would look like:
description.set_attribute("Executable", "/bin/date", TaskType.NORMAL)
So, I'd love to see a show of hands for the different versions - maybe we can cut the thread short.
I opt for E: one syntax for all cases is the simplest solution.
best, Mathijs
-- Nothing is ever easy. -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
-- Nothing is ever easy.
On Mon, 2009-11-09 at 22:57 +0100, Andre Merzky wrote:
I think we have an agreement on E then:
E) description.set_attribute ("Executable", "/bin/date");
So, no dict, no properties, but a simple plain SAGA attribute API.
Nice! One leftover thing: should the API provide string constants (as Python class attributes) for the available SAGA attribute names? Example: description.set_attribute(JobDescription.EXECUTABLE, "/bin/date") regards, -Mathijs
We do have that in C++, and IIRC you guys also have that in Java? It nicely minimized typos on user side. If that is not against python ethics, why not put it in? Cheers, Andre. Quoting [Mathijs den Burger] (Nov 10 2009):
On Mon, 2009-11-09 at 22:57 +0100, Andre Merzky wrote:
I think we have an agreement on E then:
E) description.set_attribute ("Executable", "/bin/date");
So, no dict, no properties, but a simple plain SAGA attribute API.
Nice! One leftover thing: should the API provide string constants (as Python class attributes) for the available SAGA attribute names?
Example:
description.set_attribute(JobDescription.EXECUTABLE, "/bin/date")
regards, -Mathijs
-- Nothing is ever easy.
On Tue, Nov 10, 2009 at 10:48 AM, Andre Merzky <andre@merzky.net> wrote:
We do have that in C++, and IIRC you guys also have that in Java? It nicely minimized typos on user side.
If that is not against python ethics, why not put it in?
No, not at all. It certainly facilitates the use of the bindings. Cheers, /Manuel
Quoting [Manuel Franceschini] (Nov 11 2009):
On Tue, Nov 10, 2009 at 10:48 AM, Andre Merzky <andre@merzky.net> wrote:
We do have that in C++, and IIRC you guys also have that in Java? It nicely minimized typos on user side.
If that is not against python ethics, why not put it in?
No, not at all. It certainly facilitates the use of the bindings.
Good! thats easy then :-) A. -- Nothing is ever easy.
It is certainly doable from the technical point of view. My question is what would be the advantages of having a dict-like interface? Would that be in this form then:
If I rember the discussion from Banff correctly, the proposal was more like
jobDescription.attributes["Executable"] = "/bin/hostname"
Why not:
jobDescription["Executable"] = "/bin/hostname"
Yes, I'd also prefer this. Much shorter, and it resembles that a job description IS-A Attributes.
Well, I stand corrected, it _is_ possible by overloading __getattr__/__setattr__. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com
It is certainly doable from the technical point of view. My question is what would be the advantages of having a dict-like interface? Would that be in this form then:
If I rember the discussion from Banff correctly, the proposal was more like
jobDescription.attributes["Executable"] = "/bin/hostname"
Why not:
jobDescription["Executable"] = "/bin/hostname"
Yes, I'd also prefer this. Much shorter, and it resembles that a job description IS-A Attributes.
Well, I stand corrected, it _is_ possible by overloading __getattr__/__setattr__.
I got the context of my reply wrong. This comment was intended to be a reply for:
jobDescription.attributes.Executable = "/bin/hostname"
Not good as we have no way to ensure only proper attributes are accessed. For instance
jobDescription.attributes.Executable1 = "/bin/hostname"
will go unnoticed as Python simply creates a member Executable1 assigning the string.
Ah, I did not know this! Hmm, that would indeed be a very good reason not to use Python properties for attributes.
So here it goes again: Well, I stand corrected, it _is_ possible by overloading __getattr__/__setattr__. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com
On Thu, 2009-11-05 at 07:27 -0600, Hartmut Kaiser wrote:
So here it goes again:
Well, I stand corrected, it _is_ possible by overloading __getattr__/__setattr__.
Interesting! But wouldn't that become a bit hackish, with many possible side-effects? -Mathijs
On Thu, Nov 5, 2009 at 2:55 PM, Mathijs den Burger <mathijs@cs.vu.nl> wrote:
On Thu, 2009-11-05 at 07:27 -0600, Hartmut Kaiser wrote:
So here it goes again:
Well, I stand corrected, it _is_ possible by overloading __getattr__/__setattr__.
Interesting! But wouldn't that become a bit hackish, with many possible side-effects?
__getattr__() is only called if an (Python) instance attribute is not found via the standard lookup mechanism. __setattr__(), however, is called for every (Python) instance attribute assignment. To overload these methods has the potential of causing some trouble and overhead. In __setattr__() every attribute assignment would need to be checked against the list of valid SAGA attributes. Cheers, -- /Manuel
participants (6)
-
'Andre Merzky' -
Andre Merzky
-
Hartmut Kaiser -
Manuel Franceschini -
Mathijs den Burger -
Steve Fisher