-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
workaround for unusual region settings #370
base: master
Are you sure you want to change the base?
Conversation
one thing on this. I am tired of locale issues. we need to come up with a concrete mechanism to deal with the locale before we release. all of the locale code needs to be in a single location instead of piece here and piece there. Now I can manually grab each of the various numeric components using the Windows API. and create our own custom locale handler that will not care what the language is or the locale for that matter. it will grab the needed values from Windows and assign them where they need to be. It would not be to difficult to do that. This would also eliminate any possibility of an issue in the future. wee couple that with the language classes and I think it might be a winning combination that is not going to be prone to any problems. specifically because we are then not dependent on what some other module grabs from Windows. Which we are finding that these other modules are not gathering and compiling the information properly. It's not our code that has the issues. and instead of us band-aiding the problem. we should grab the bull by the horns and do it right. |
as it turns out this problem is not a problem in python. it is a problem with Windows build 1809 specifically. the most recent update. Microsoft sticks it to us once again. http://www.eventghost.net/forum/viewtopic.php?f=2&t=10288&p=52829#p52829 |
I think that I may have located the issue. here is the code from the locale module for setting the locale. def setlocale(category, locale=None):
if locale and not isinstance(locale, (_str, _unicode)):
# convert to string
locale = normalize(_build_localename(locale))
return _setlocale(category, locale) we are passing "" to the local argument. ok so here is the _setlocale function in the _locale extension module. static PyObject*
PyLocale_setlocale(PyObject* self, PyObject* args)
{
int category;
char *locale = NULL, *result;
PyObject *result_object;
if (!PyArg_ParseTuple(args, "i|z:setlocale", &category, &locale))
return NULL;
#if defined(MS_WINDOWS)
if (category < LC_MIN || category > LC_MAX)
{
PyErr_SetString(Error, "invalid locale category");
return NULL;
}
#endif
if (locale) {
/* set locale */
result = setlocale(category, locale);
if (!result) {
/* operation failed, no setting was changed */
PyErr_SetString(Error, "unsupported locale setting");
return NULL;
}
result_object = PyString_FromString(result);
if (!result_object)
return NULL;
/* record changes to LC_CTYPE */
if (category == LC_CTYPE || category == LC_ALL)
fixup_ulcase();
/* things that got wrong up to here are ignored */
PyErr_Clear();
} else {
/* get locale */
result = setlocale(category, NULL);
if (!result) {
PyErr_SetString(Error, "locale query failed");
return NULL;
}
result_object = PyString_FromString(result);
}
return result_object;
} in the report of the problem the error if (locale) {
/* set locale */
result = setlocale(category, locale);
if (!result) {
/* operation failed, no setting was changed */
PyErr_SetString(Error, "unsupported locale setting");
return NULL;
} now evn tho we are passing "" to the locale parameter for some reason it is I think that this is thee code block we now need to have run. } else {
/* get locale */
result = setlocale(category, NULL);
if (!result) {
PyErr_SetString(Error, "locale query failed");
return NULL;
}
result_object = PyString_FromString(result);
} so maybe changing we can do a simple import locale
try:
locale.setlocale(locale.LC_ALL, '')
except locale.Error:
locale.setlocale(locale.LC_ALL, None)
thee only way to know is a user is going to have to bee running build 1806 of Windows |
#369