On Wed, Oct 16, 2013 at 3:38 PM, John S Warren <jswar...@us.ibm.com> wrote:
> Doug Hellmann <doug.hellm...@dreamhost.com> wrote on 10/16/2013 03:11:12 > PM: > > > > > > This doesn't quite match my understanding. > > > > IIUC, approach 1 was taken during havana and the resulting class did > > not behave enough like a string to work everywhere (specifically, > > with logging for locales that did not use UTF-8 or ASCII encoding), > > so the feature was disabled at the last minute. > > Approach 1 includes extending the built-in text type (e.g. unicode), > which is not what was done in Havana, and is an alternative way of > addressing the logging issue. In addition to fixing the logging > Yes, you're right, that was the proposed fix, not the original solution. I mixed up the timing. > issue, extending the built-in text type would eliminate the need to > override a lot of the standard string-manipulation methods that are > being overridden in the current Message implementation. I'm not sure > if that's what the term "magic" referred to in the meeting > discussion, but it's something that bothers me about the status quo. > We need, at some point in the lifecycle of a Message instance, to tell the message what locale to use for its translation. At that point, we have code that knows the message is not a string. If we already require code like that, then we can change the API of Message to be explicit about producing the translated string, and Message does not need to pretend to be something it isn't. Doug > > Thanks for your reply, > > John Warren > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
