Nicolas Hainaux <nh.te...@gmail.com> added the comment:

Sorry, I did not realize that using the word "unset" was completely misleading: 
I only meant "before any use of locale.setlocale() in python". So I'll rephrase 
this all, and add details about the python versions and platforms in this 
message.

So, first, I do not unset the environment variables from the shell before 
running python.

The only steps required to reproduce this behaviour are: open a terminal and 
run python3:

Python 3.6.5 (default, May 11 2018, 04:00:52) 
[GCC 8.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getlocale()
('fr_FR', 'UTF-8')  # Wrong: the C locale is actually in use, so (None, None) 
is expected


Explanation: when python starts, it runs using the C locale, on any platform 
(Windows, Linux, BSD), any python version (2, 3...), until locale.setlocale() 
is used to set another locale. This is expected (the doc says so in the 
getdefaultlocale() paragraph that you mentioned) and can be confirmed by the 
outputs of locale.localeconv() and locale.str().

So, before any use of locale.setlocale(), locale.getlocale() should return 
(None, None) (as this value matches the C locale).

This is the case on Windows, python2 and 3, and on Linux and FreeBSD python2.

But on Linux and FreeBSD, python>=3.4 (could not test 3.0<=python<=3.3), 
locale.getlocale() returns the value deduced from the environment variables 
instead, like locale.getdefaultlocale() already does, e.g. ('fr_FR', 'UTF-8').

All python versions I tested are from the platform distributors (3.7 only is 
compiled, but it's an automatic build from an AUR). Here is a more detailed 
list of the python versions and Linux and BSD platforms where I could observe 
this behaviour:

- Python 3.4.8, 3.5.5, 3.6.5 and 3.7.0rc1 on an up to date Manjaro (with "LTS" 
kernel): Linux 4.14.48-2-MANJARO #1 SMP PREEMPT Fri Jun 8 20:41:40 UTC 2018 
x86_64 GNU/Linux

- Python 3.6.5 on Xubuntu 18.04 (as virtual box guest) Linux 4.15.0-23-generic 
#25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

- Python 3.4.6 on openSUSE Leap 42.3 (as virtual box guest) Linux 
4.4.76-1-default #1 SMP Fri Jul 14 08:48:13 UTC 2017 (9a2885c) x86_64 x86_64 
x86_64 GNU/Linux

- Python 3.4.8 and 3.6.1 on FreeBSD 10.4-RELEASE-p8 FreeBSD 10.4-RELEASE-p8 #0: 
Tue Apr  3 18:40:50 UTC 2018     
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

Problem of this behaviour on Linux and FreeBSD python>=3.4 is first, of course, 
that it's not consistent throughout all platforms, and second, that it makes it 
impossible for a python library to guess, from locale.getlocale() if the user 
(a python app) has set the locale or not (and is actually still using the C 
locale). (It is still possible to rely on locale.localeconv() to get correct 
elements).

Hope this message made things clear now :-)

----------
versions: +Python 3.4, Python 3.5, Python 3.7

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33934>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to