[SAGA-RG] SAGA attributes as Python dictionaries?

['Andre Merzky']

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 at 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.