Message320412
| Author |
ncoghlan |
| Recipients |
docs@python, ncoghlan, ned.deily, vstinner, zezollo |
| Date |
2018年06月25日.10:50:11 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1529923811.85.0.56676864532.issue33934@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Ah, part of the confusion is that I misremembered the command we run implicitly during startup - it's only `setlocale(LC_CTYPE, "")`, not `setlocale(LC_ALL, "")`.
However, the default category for `locale.getlocale()` is `LC_CTYPE`, so it reports the text encoding locale configured during startup, not the C level default.
The difference on Windows is expected - the startup code that implicitly runs `setlocale(LC_CTYPE, "")` doesn't get compiled in there.
So I think we have a few different potential ways of viewing this bug report:
1. As a docs issue, where we advise users to run `locale.getlocale(locale.LC_MESSAGES)` to find out whether or not a specific locale really has been configured (vs the interpreter's default text encoding change that runs implicitly on startup)
2. As a defaults change for 3.8+, where we switch `locale.getlocale()` over to checking `locale.LC_MESSAGES` instead of `locale.LC_CTYPES`, since the interpreter always sets the latter on startup, so it doesn't convey much useful information.
3. As (1) for maintenance releases, and as (2) for 3.8+ |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2018年06月25日 10:50:11 | ncoghlan | set | recipients:
+ ncoghlan, vstinner, ned.deily, docs@python, zezollo |
| 2018年06月25日 10:50:11 | ncoghlan | set | messageid: <1529923811.85.0.56676864532.issue33934@psf.upfronthosting.co.za> |
| 2018年06月25日 10:50:11 | ncoghlan | link | issue33934 messages |
| 2018年06月25日 10:50:11 | ncoghlan | create |
|