<font size=2 face="sans-serif">Ben Nemec wrote:</font>
<br>
<br><font size=2 face="sans-serif">> Have you seen the discussion from
the last Oslo meeting?</font>
<br><font size=2 face="sans-serif">> </font><a href="http://eavesdrop.openstack.org/meetings/oslo/2013/oslo.2013-10-11-14.00.log.txt"><font size=2 face="sans-serif">http://eavesdrop.openstack.org/meetings/oslo/2013/oslo.2013-10-11-14.00.log.txt</font></a>
<br>
<br><font size=2 face="sans-serif">Unfortunately, I missed that meeting.
 I don't want to dwell on this</font>
<br><font size=2 face="sans-serif">too much, but I would like add some
thoughts that may not have</font>
<br><font size=2 face="sans-serif">been considered.</font>
<br>
<br><font size=2 face="sans-serif">So I guess the choice there was option
#3.  For what it's worth,</font>
<br><font size=2 face="sans-serif">getting lazy translation to work in
Glance was a bit messier, because</font>
<br><font size=2 face="sans-serif">_() is being used in creating objects
that are converted into json</font>
<br><font size=2 face="sans-serif">and this fails because the json library
does not know how to handle</font>
<br><font size=2 face="sans-serif">Message objects.  It's also possible
that the output of _() ends up</font>
<br><font size=2 face="sans-serif">being used for other things as well.</font>
<br>
<br><font size=2 face="sans-serif">I don't quite understand why one wouldn't
go with option #1, thereby</font>
<br><font size=2 face="sans-serif">avoiding any issues with Message objects
being used where unicode</font>
<br><font size=2 face="sans-serif">objects are normally used.  The
code may be more complicated, but the</font>
<br><font size=2 face="sans-serif">complications are limited to one location
(oslo) and it avoids other</font>
<br><font size=2 face="sans-serif">potential issues later on by people
assuming _() produces</font>
<br><font size=2 face="sans-serif">unicode objects--this stuff is not fun
to debug even if you're aware</font>
<br><font size=2 face="sans-serif">of how _() has been tweaked.  Option
#3 seems more</font>
<br><font size=2 face="sans-serif">like a tactical choice, not a strategic
one.  Why not get it right in</font>
<br><font size=2 face="sans-serif">one place, rather than possibly having
to make several accommodations</font>
<br><font size=2 face="sans-serif">in the consuming projects or elsewhere
in oslo?  Keep in mind that the</font>
<br><font size=2 face="sans-serif">logging fix is not necessary if Message
extends six.text_type. Also</font>
<br><font size=2 face="sans-serif">keep in mind that the messiest part
of Message is the __mod__ method</font>
<br><font size=2 face="sans-serif">and the translation mechanism, i.e.
getting rid of the __unicode__ and</font>
<br><font size=2 face="sans-serif">__str__ methods does not reduce the
complexity of the Message class</font>
<br><font size=2 face="sans-serif">significantly, yet it makes consuming
it more difficult.  A lot of the</font>
<br><font size=2 face="sans-serif">messiness of making Message behave like
a string type goes away</font>
<br><font size=2 face="sans-serif">if it extends such a type.</font>
<br>
<br><font size=2 face="sans-serif">Hope that's useful.<br>
<br>
John Warren</font>