Questions on the Locale issue

I have some questions regarding the handling of the issue 1637. I’ve seen that you released a new version, that fixes that point. It was an actual issue that some end users reported to me. And I fixed this with a workaround as Robin suggested in the past. This issue is now part of what I’ll scrutinize when testing this new wxPython version.

First, I had real difficulty to reproduce this issue. It was only triggered on a limited number of PCs, out of my reach (at the end user side). On this matter, do you know any easy and fast method to configure a Windows system to trigger this issue? This way I could easily test on my own in the developement process, and observe whether the 4.2 version is fixing this point.

I’m taking some time to open a discussion here, because there are some people who complain about the quality, or express doubt about the real effect of your issue fixing. I quote : “It is just the workaround, It doesn’t solve the problem but merely shuffles it around. Please revert.” So I want to understand what are these concerns? What is the actual issue remaining with this fix? Is is about the locale input which can’t be set as the Windows desktop one?

Still, as far as I can see, the fix seems to be exactly what I did to fix this issue (based on what Robin suggested). And to me, it works fine with this modification. I can’t see any issues with my app. But I don’t use date formatting not advanced locale input stuff. So what would be some adverse effects of this change?

By the way, thank you for this new version. One key point for me is the ability to run on Python3.10. I’ve seen many people having a bad time trying to install wxPython on 3.10, and now this is fixed. For these cases, I suggested them to remove 3.10 and stick to 3.9. I feel that we can also benefit a lot from the new wxWidgets 3.2 version. :slight_smile:

The issue is setting any locale that is not wx.LANGUAGE_DEFAULT.

Try this:

import wx,locale,datetime
app = wx.App()
loc = wx.Locale(wx.LANGUAGE_ENGLISH_US)
print(datetime.datetime.strptime('2020', "%Y"))
Outcome

Using 4.2.0 msw on Python 3.10.5-64:

Traceback (most recent call last):
  File "c:\work\locset.py", line 4, in <module>
    print(datetime.datetime.strptime('2020', "%Y"))
  File "C:\flonidan\env\Python310\lib\_strptime.py", line 268, in <module>
    _TimeRE_cache = TimeRE()
  File "C:\flonidan\env\Python310\lib\_strptime.py", line 182, in __init__
    self.locale_time = LocaleTime()
  File "C:\flonidan\env\Python310\lib\_strptime.py", line 69, in __init__
    self.lang = _getlang()
  File "C:\flonidan\env\Python310\lib\_strptime.py", line 28, in _getlang
    return locale.getlocale(locale.LC_TIME)
  File "C:\flonidan\env\Python310\lib\locale.py", line 603, in getlocale
    return _parse_localename(localename)
  File "C:\flonidan\env\Python310\lib\locale.py", line 511, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: en-US

The problem is in the Python stdlib: https://github.com/python/cpython/issues/87281. wxWidgets calls the C library setlocale function with a value that is perfectly legitimate but that locale.getlocale chooses to reject.

I can no longer remember what specific issue I saw with Change InitLocale to just do locale.setlocale(locale.LC_ALL, "C") to … · wxWidgets/Phoenix@040c59f · GitHub. I think my conclusion at the time was that the problem couldn’t be properly solved in App.InitLocale, whatever you write there, and I wanted to avoid a proliferation of half-baked workarounds. Something like that.