Luke Imhoff writes:

Does your terminal support unicode and if it does does python know that? Python should only beconverting down to ascii if it doesn't think your terminal can display unicode.

I never had this problem before. The terminal is a kde3 Konsole. 0 froh@byron:/tmp $ echo $TERM xterm+sl 0 froh@byron:/tmp $ echo $LANG en_EN.UTF-8 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

Michal Čihař writes:

Dne Wed, 01 Jul 2009 07:53:57 -0500 Luke Imhoff napsal(a):

...

Does your terminal support unicode and if it does does python know that? Python should only beconverting down to ascii if it doesn't think your terminal can display unicode.

In default configuration (in 2.x branch) Python always tries to print ascii. Not sure whether this is changed on SUSE, but for Debian this thing is kept.

can you guys reproduce the problem with this command line? osc request show 12780 I'm on openSUSE 11.1 with obs 0.120 from openSUSE:Tools. If so, I'm happy to fix this --- a pointer to how to set the utf-8 output configuration is appreciated. What I don't get is why "print s" from the debugger does it right, while the print in osc fails in my debugging session. 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

On 2009-07-02 08:19:18 +0200, Michal Čihař wrote:

...

What I don't get is why "print s" from the debugger does it right, while the print in osc fails in my debugging session.

Just played a bit with the source and I have to admit that I do not understand how the string conversion works :-).

These work fine:

print r.__str__() print unicode(r)

But this one does not:

print r

That's due to the implementation of the print function. It implicitly calls str() on the string returned by __str__() which fails in case the string is a unicode object which contains chars which cannot be converted to ascii (in this case 0xfc). It seems that if you directly pass a string or unicode object to the print call no str() method is called. Another question is if the usage of __str__() is correct in this case because we obviously can't ensure that the result can be converted to ascii - so should we use __unicode__() instead of __str__() in this case? Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Hi Dne Fri, 03 Jul 2009 10:09:06 +0200 Susanne Oberhauser napsal(a):

The sys.setdefaultencoding function is disabled after site initialization on purpose: http://www.python.org/dev/peps/pep-0100/

The purpose isn't clear, though.

I've found somewhere, that this function was supposed to be temporary until developers decide what should be default encoding. Unfortunately it was not removed later and is still there what only increases confusion.

There is thre fixes to this:

1. we enable in syte.py the use of the locale setting

Problem with this is that you will most likely break applications which do rely on default settings.

2. we work around the IMNSHO braindead disablement of "setdefaultencoding":

import sys, locale reload(sys) sys.setdefaultencoding(locale.getdefaultlocale()[1])

3. We scatter explicit unicode awareness to every place we possibly handle unicode strings strings.

I *strongly* opt for #1 or #2. #3 is just so plain inelegant, I refuse to do that. It's like checking return codes after exceptions have been invented.

4. Wait for python 3.0 :-). -- Michal Čihař | http://cihar.com | http://blog.cihar.com

On 2009-07-03 13:24:59 +0200, Susanne Oberhauser wrote:

Michal Čihař writes:

...

...

There is thre fixes to this:

1. we enable in syte.py the use of the locale setting

Problem with this is that you will most likely break applications which do rely on default settings.

yes.

...

...

2. we work around the IMNSHO braindead disablement of "setdefaultencoding":

import sys, locale reload(sys) sys.setdefaultencoding(locale.getdefaultlocale()[1])

3. We scatter explicit unicode awareness to every place we possibly handle unicode strings strings.

I *strongly* opt for #1 or #2. #3 is just so plain inelegant, I refuse to do that. It's like checking return codes after exceptions have been invented.

4. Wait for python 3.0 :-).

ok, that means #2 for now, right?

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:) Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 2009-07-03 23:38:14 +0200, Susanne Oberhauser wrote:

Marcus Hüwe 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_ ?

That's quite ugly:)

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?

No they might break by the current implementation of the __str__() method and not by your change. But there's no "non-ugly" fix for this... so IMHO the best is if you commit your #2 diff so that at least osc can handle it correctly. Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

2009/7/2 Vincent Petry :

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi,

Question: one of my submit requests to the games OBS project has been approved (GoOllie). In the past, when that happened, the build and publish were enabled by default. But for that package, everything is disabled. Is this a new default ? (which is a good idea in my opinion)

Before I re-enable it, I just want to be sure it hasn't been disabled manually on purpose, maybe to save some build server for other packages to be built with higher priority.

I accepted it, but added a message asking for some minor changes before you published it. See the output from osc request show 13353. You should have received an email... but since some time ago I don't receive them when someone accept a package from me (I receive it for requests). I have that configured in hermes... **bug**? Please, before publishing it: - Remove the "Vendor" tag (the OBS adds it and putting it in the spec file overrides that) - Add a menu entry (.desktop file and icon) - And something I didn't saw/said in the accept message: the .py files should be precompiled as is said at http://en.opensuse.org/Packaging/Python#Byte_Compiled_Files -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Cristian, Thank you for accepting my request. I will fix the points you mentionned before enabling the build. I indeed didn't receive any message from you from the submitreq. Thanks, Vincent Cristian Morales Vega a écrit :

2009/7/2 Vincent Petry :

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi,

Question: one of my submit requests to the games OBS project has been approved (GoOllie). In the past, when that happened, the build and publish were enabled by default. But for that package, everything is disabled. Is this a new default ? (which is a good idea in my opinion)

Before I re-enable it, I just want to be sure it hasn't been disabled manually on purpose, maybe to save some build server for other packages to be built with higher priority.

I accepted it, but added a message asking for some minor changes before you published it. See the output from osc request show 13353. You should have received an email... but since some time ago I don't receive them when someone accept a package from me (I receive it for requests). I have that configured in hermes... **bug**?

Please, before publishing it: - Remove the "Vendor" tag (the OBS adds it and putting it in the spec file overrides that) - Add a menu entry (.desktop file and icon) - And something I didn't saw/said in the accept message: the .py files should be precompiled as is said at http://en.opensuse.org/Packaging/Python#Byte_Compiled_Files -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkpMshcACgkQSSdxpfEEQEzdzgCeK3Mrhxlbs0UKufpRAHLJVYYw ZmMAn36ECGLRVXzNv87xpajfp7fRyHXn =mDkz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org