Marcus Hüwe
Hmm IMHO this is just a workaround which doesn't really fix the problem. The problem is that our implementation of __str__() is wrong in the sense of the return "type". We need to ensure that everything __str__() returns can be converted to the str type. For all other cases we should use __unicode__() but then there might be cases where "print obj" doesn't print out the expected result because print doesn't use __unicode__()... Actually my main "concern" with your workaround is that it will break other applications which use osc and rely on the correctness of __str__(). This all seems to be quite complicated:)
The alternative is to make the encoding selection explicit throughout the code, like this: def __str__(self): s = ... return s.encode("utf-8") # evil as the locale setting may be different # return s.encode(locale.getdefaultlocale()[1]) Now how ugly is _that_ ? All #2 is trying to mimic is python3 behavior: it pretends all strings are unicode, and it assumes, that when str() comes into play, human interaction is close so coercion to the external representation as suggested by the locale is smart. Python3 will also go that route, btw: all strings will be unicode. How many third party plugins into osc do you think we realistically may have that will break by this change? S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org