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: 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, -- /Manuel