At 01:27 PM 1/18/05 -0800, Donn Denman wrote:
You mentioned how often you curse those __str__ methods, on items like EmailAddress, and I've been thinking maybe we should move them. You hate is that they are hooked in to str(), so you end up calling them by accident, often when debugging as I recall. What I like is that there's a known way to convert things to a nice user-readable representation. The Chandler convention of using the "displayName" attribute doesn't seem to work well in some cases, because you may need a method to decide how to display. You probably want a method for ref collections, and even things like EmailAddress have a couple different ways that they display based on whether or not a fullName attribute is present. So I figured __str__ was the standard way to do this when a method is needed. But there's no reason we need to use __str__. Maybe we should use a display() method instead of __str__, and both of us will be happy?

We don't actually have very many __str__ methods yet, so it wouldn't be too hard to make a change like this. It would be great if ref collections knew how to display themselves as a nice comma-separated list of displayed items. Most items would inherit a default display() method that just uses the displayName attribute.

What do you think? Should we move the __str__ methods? Is there some other standard that we should be adopting? Let me know if you think this is a good idea, and I'll try to work with you on this.

The thing about __str__ and __repr__ is that they should never ever *ever* raise an uncaught error, if you want to be able to debug them. In the case of persistent objects like in Chandler, this means that if __str__ or __repr__ use item attributes, they must be able to handle any errors that result from accessing that item. One way to do this would be to have a default __str__ and __repr__ methods in a content item base class that look like this:


    def __str__(self):
        try:
            return self.displayName
        except:
            # fallback to simple known-failsafe rendering
            # possibly incorporating error info

For classes that need a method to compute 'displayName', just use a 'property'; if it breaks you'll still get the default representation and you'll know right away your property is broken.

Also, the above code isn't perfect, as it will eat errors like KeyboardInterrupt. In general, having bare 'except' statements is a bad idea unless you're going to log the exception in some way, but for __str__ that cure would be worse than the disease. :)

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Reply via email to