job.description should not allow to set unsupported attributes

[andre-merzky]

The following should raise an exception::

js.stdout = '/tmp/out'

as the correct attribute name would be 'jd.output'.

[oweidner]

It's hardly possible in Python to prevent the programmer to add arbitrary attributes to a class from "outside".

While there is a non-trivial way to implement this, trowing in a situation like that is considered absolutely un-pythonesqe. If you use the saga-api get_attribute, set_attribute methods, you are save and you will get the expected exception.

[andre-merzky]

Well, I don't think it is that difficult really. shouldn't the following do the trick? ::

def __setattr__(self, key, val):
  if key in allowed_attribs_:
    object.__setattr__(self, key, val)
  else:
    raise BadParameter('attribute %s is not defined on job.Description' % key)

[oweidner]

Sure.

But it really is common practice in Python to 'tag' your own attributes to library objects for all sorts of reasons. Python is not C++ and it really does not want to follow a strict encapsulation concept at all. I would really like to avoid writing "Cython++" library code...

On Jun 11, 2012, at 8:33 AM, Andre Merzky wrote:

Well, I don't think it is that difficult really. shouldn't the following do the trick? ::

def setattr(self, key, val): if key in allowedattribs: object.setattr(self, key, val) else: raise BadParameter('attribute %s is not defined on job.Description' % key)

---

Reply to this email directly or view it on GitHub: https://github.com/saga-project/bliss/issues/55#issuecomment-6244353

[andre-merzky]

I don't think you can have it both ways -- claiming to implement the GFD.90 semantics, and doing the laissez faire approach to the API.

Bliss (and all SAGA python bindings in general) deviate from the GFD.90 IDL in syntax where that makes the API simpler to use for python programmers, while maintaining the SAGA semantics. Changing the semantics in a laissez faire way OTOH has too many side effects. The example above may look innocent, but please consider the following:

• how will plugins handle attributes which are not defined in GFD.90? not defined in Bliss?
• will new attributes, previously set as properties, be listed on list_attributes()?
• can they, once set as properties, be changed/deleted via the attribute interface?

Basically, you (a) create two different entry points to some API entity, both differing in semantics, and (b) leave the backend behavior unspecified.

If adding custom properties in Python is central and important (I do not know), then I see two options: allow it, but do not pass those settings down to the plugins (I don't think that this is a good idea, as it is lacking transparency), or don't allow it, and let the developer inherit from job description, to obtain a class with custom properties. Do you see any other options?

My $0.02, Andre.

[oleweidner]

All API-related issues will be addressed when we implement the proper Python language bindings after 1.0.