[SAGA-RG] SAGA attributes as Python dictionaries?

[Andre Merzky]

Quoting [Manuel Franceschini] (Nov 04 2009):
> 
> 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"

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"

?

One question about both approaches though, and to also about both
approaches you list below: how would async ops be realized?

Best, Andre


> 
> 1)  jobDescription["Executable"] = "/bin/hostname")
> 
> Where 'jobDescription' is an object. Why not having just class
> attributes (as Mathijs showed in the first e-mail), as in:
> 
> 2)  jobDescription.Executable = "/bin/hostname"
> 
> 
> IMHO, one of the most important Pythonic properties is having exactly
> _one_ way of achieving a task. In other words, having two different
> ways (even if the added way is slightly simpler) is not what I would
> want. Therefore, if we decide to expose one of the above ways to the
> end user, it should be the _only_ one, while
> jobDescription.set_attribute(...) should not be part of the API for
> the end user then.
> 
> My 2 cents.
> 
> Cheers,
-- 
Nothing is ever easy.