[SAGA-RG] SAGA attributes as Python dictionaries?

[Manuel Franceschini]

On Thu, Nov 5, 2009 at 2:00 PM, Andre Merzky <andre at 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 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.

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