wxPython 2.5.4.1 unicode on XP: no unicode?

wxPython Users
1

Did it work with a unicode build of 2.5.3.1?

It did.
You don't care about backwards compatibility, do you?
I find it a bit strange that this error occurrs even in PyCrust etc. that are official part of wxPython.

If Stani would fix this issues, would it work also on older wx versions?
(SPE says it should run on 2.5.2.8)

unicode objects to/from wxString objects. Previously the default
Python encoding was always used, but unless the user had tweaked their
sitecustomize.py file it is always "ascii", which would result in
errors if the strings contained character codes >= 128.

SPE writes the user default into sitecustomize.py and relies on that.

Now the startup code is going to set the default encoding
wxPython uses to convert to/from unicode to the value of
locale.getdefaultlocale()[1]
which is certainly not utf8 for you.

Alas, no. I tried to set LOCALE and LANG variables in Windows, but that doesn't help.
Any ideas? (I'm working on WinXP, but my home system is MacOS X...)

It also depends on how SPE and etc. are loading the files. If

I forwarded your hint to the SPE bug tracker.

Anyway, try adding something like this to the SPE code after
it imports
wx and see if that fixes it for you:
wx.SetDefaultPyEncoding("utf8")

In Child.py it helps. Thank you.

That doesn't fix the Notebook sizer problem (I didn't mention yet), but it's a step on the way.

Best regards,
Henning Hraban Ramm
Südkurier Medienhaus / MediaPro
Support/Admin/Development Dept.

2

Did it work with a unicode build of 2.5.3.1?

It did.
You don't care about backwards compatibility, do you?

I do, that's why I asked and then tried to make some guesses as to how it could have worked for you before. The change was made to allow applications a way to work around the fact that most people never create a sitecustomize.py or change the default encoding within it.

Your situation has reminded me that some people *do* change the default encoding and that it could be different than the default locale's ecoding, so I think that I will change wxPython to only change the encoding that it uses for conversions to the locale setting if sys.getdefaultencoding() is still equal to "ascii".

I find it a bit strange that this error occurrs even in PyCrust etc. that are official part of wxPython.

If Stani would fix this issues, would it work also on older wx versions?
(SPE says it should run on 2.5.2.8)

SetDefaultPyEncoding is new in 2.5.4.1, but SPE can check the version and still do it the old way if desired. Or it can do nothing and start working again after I make the change above by continuing to depend on setting the system default in sitecustomize.

unicode objects to/from wxString objects. Previously the default
Python encoding was always used, but unless the user had tweaked their
sitecustomize.py file it is always "ascii", which would result in
errors if the strings contained character codes >= 128.

SPE writes the user default into sitecustomize.py and relies on that.

Applications should never modify sitecustomize.py themselves. That is supposed to be reserved for sysadmins to make site-wide defaults. The advice I've seen in the past is that apps should never depend on a specific default encoding but should instead be written to be default encoding independent. By adding the SetDefaultPyEncoding I've made a way for apps to be able to do that a lot easier. By setting the default to the default locale's encoding I've hopefully corrected a lot of people's bugs where the apps didn't take care to handle string/unicode conversions properly themselves.

Now the startup code is going to set the default encoding wxPython uses to convert to/from unicode to the value of locale.getdefaultlocale()[1] which is certainly not utf8 for you.

Alas, no. I tried to set LOCALE and LANG variables in Windows, but that doesn't help.
Any ideas? (I'm working on WinXP, but my home system is MacOS X...)

I don't think that Windows uses the env variables, but the system-wide locale settings made in the control panel someplace.

···

Henning.Ramm@mediapro-gmbh.de wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!