Open Stack

Ben Nemec wrote:

> Have you seen the discussion from the last Oslo meeting?
> 
http://eavesdrop.openstack.org/meetings/oslo/2013/oslo.2013-10-11-14.00.log.txt

Unfortunately, I missed that meeting.  I don't want to dwell on this
too much, but I would like add some thoughts that may not have
been considered.

So I guess the choice there was option #3.  For what it's worth,
getting lazy translation to work in Glance was a bit messier, because
_() is being used in creating objects that are converted into json
and this fails because the json library does not know how to handle
Message objects.  It's also possible that the output of _() ends up
being used for other things as well.

I don't quite understand why one wouldn't go with option #1, thereby
avoiding any issues with Message objects being used where unicode
objects are normally used.  The code may be more complicated, but the
complications are limited to one location (oslo) and it avoids other
potential issues later on by people assuming _() produces
unicode objects--this stuff is not fun to debug even if you're aware
of how _() has been tweaked.  Option #3 seems more
like a tactical choice, not a strategic one.  Why not get it right in
one place, rather than possibly having to make several accommodations
in the consuming projects or elsewhere in oslo?  Keep in mind that the
logging fix is not necessary if Message extends six.text_type. Also
keep in mind that the messiest part of Message is the __mod__ method
and the translation mechanism, i.e. getting rid of the __unicode__ and
__str__ methods does not reduce the complexity of the Message class
significantly, yet it makes consuming it more difficult.  A lot of the
messiness of making Message behave like a string type goes away
if it extends such a type.

Hope that's useful.

John Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/9a44af61/attachment.html>