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