[issue30755] locale.normalize() and getdefaultlocale() convert C.UTF-8 to en_US.UTF-8

2019-07-23 Thread Gordon Messmer
Gordon Messmer added the comment: As an example, let's consider dnf's i18n setup: try: dnf.pycomp.setlocale(locale.LC_ALL, '') except locale.Error: # default to C.UTF-8 or C locale if we got a failure. try: dnf.pycomp.setlocale(l

[issue30755] locale.normalize() and getdefaultlocale() convert C.UTF-8 to en_US.UTF-8

2019-07-23 Thread Gordon Messmer
Change by Gordon Messmer : -- keywords: +patch pull_requests: +14696 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14925 ___ Python tracker <https://bugs.python.org/issu

[issue30755] locale.normalize() and getdefaultlocale() convert C.UTF-8 to en_US.UTF-8

2019-07-08 Thread Gordon Messmer
Gordon Messmer added the comment: > I agree we shouldn't be aliasing C.UTF-8 to en_US.UTF-8 though What can we do about reverting that change? Python's current behavior causes unexpected exceptions, especially in containers. I'm currently debugging test failures in a

[issue30755] locale.normalize() and getdefaultlocale() convert C.UTF-8 to en_US.UTF-8

2019-07-08 Thread Gordon Messmer
Gordon Messmer added the comment: > I can see that it might be helpful to provide such a conversion if > C.UTF-8 doesn't exist and en_US.UTF-8 does That can't happen. The "C" locale describes the behavior defined in the ISO C standard. It's built-in to gli

[issue34138] imaplib RFC 6855 issue

2018-09-19 Thread Gordon Messmer
Gordon Messmer added the comment: PR 9436 should resolve the issue. Since the RFC requires the "UTF8 (" prefix in the "data" and not in the literal, that had to be moved into the _command function. This change should only affect the append() use, as that is currently the