__unicode__ vs. __str__: not quite parallel?

[Henry S. Thompson]

If you call str(object), and object's class has a __str__ method, the
  value is the value of the __str__ method;

If you print an object to a normal stream, and object's class has a
  __str__ method, what appears is the result of the __str__ method.

If you call unicode(object), and object's class has a __unicode__ method, the
  value is the value of the __unicode__ method;

So far so good, but read on . . .

If you print an object to a unicode stream, and object's class has a
  __unicode__ method, what appears is the result of . . .

_not_ the __unicode__ method, but the __str__ method, if there is one,
otherwise the usual default.

Is this a bug or a feature?  I had hoped that by defining __unicode__
methods for my objects, and resolutely using unicode streams, I would
have a self-consistent situation, but I appear to have to do the work
twice, by defining __str__ methods that call the __unicode__ method and
encode the result.  I've searched the archives but found no joy for
this one -- any help out there?

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2002, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht at cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/
 [mail really from me _always_ has this .sig -- mail without it is forged spam]