Mailinglist Archive: opensuse-buildservice (312 mails)

< Previous Next >
Re: [opensuse-buildservice] osc umlaut problem
  • From: Susanne Oberhauser <froh@xxxxxxxxxx>
  • Date: Fri, 03 Jul 2009 23:38:14 +0200
  • Message-id: <s2iy6r530s9.fsf@xxxxxxxxxxxxx>
Marcus Hüwe <suse-tux@xxxxxx> writes:

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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups