[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