[Dev] Those annoying __str__ methods

John Anderson john at osafoundation.org
Tue Jan 18 13:45:42 PST 2005


Donn:

I've noticed this with certain blocks -- they print in Wing as a list of 
UUIDs instead of the block itself. Is that because of the same problem?

John

Donn Denman wrote:

> Andi,
>
> 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 /display/ed 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.
>
> - Donn
>
>------------------------------------------------------------------------
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Dev" mailing list
>http://lists.osafoundation.org/mailman/listinfo/dev
>  
>



More information about the Dev mailing list