@Timo_Harboe_Nielsen @Ukrutony
Rhino 8 has not received any changes related to handling of locales in its python environment so if Rhino 8 > SR30 is behaving differently, I am almost entirely sure this is not the scripting environment.
This is also a complicated issue where I do not control all the ends. Here are a few things to note:
- The problem is Windows reporting BCP-47 locale names (
en-USwith a dash) instead of POSIX-style names (en_USwith an underscore). This throws off python’slocalemodule on Windows and affects any python module importing the locale.pandasjust happens to be the most popular one here
- Python 3.12+ have reworked the
localemodule implementation on Windows to fix this problem. So I expect we should not be seeing this in Rhino 9 that uses python 3.13 - We shipped Rhino 8 with a system that script editor would attempt to fix the locale name on startup but I quickly realized this affects Rhino’s localization formatting since the locale is an application-wide setting.
- So far a variation of this workaround has worked for most people.
With the help of Claude (to get more historical context on this error), I made a python module that attempts for fix this in two ways: Correct the locale name from BCP-47 to POSIX, and also override the locale.getlocale function so it does not throw exceptions.
Put this somewhere on your python search paths and import before pandas like this:
import fix_locale
import pandas
It can also be included as a Rhino startup command like:
_-ScriptEditor _R (
#! python 3
import fix_locale
)
Let me know if this works. If the patching of locale.getlocale resolves the problem, I can put that in Rhino permanently.
fix-locale.py (2.4 KB)