On 19.03.2021 14:57, Inada Naoki wrote:
>
> Background: PEP 597 adds new `encoding="locale"`option to open() and
> TextIOWrapper(). It is same to `encoding=None` for now, but it means using
> "locale encoding" explicitly.
>
> But this is wrong in UTF-8 mode.
Please address UTF-8 mode
On 19.03.2021 14:47, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> - If you add "current", people will rightly ask: then what do all the
>> other APIs in the locale module return ? Of course, they all return
>> the current state of settings :-) So this is unnecessary as well.
On 19.03.2021 12:35, Eryk Sun wrote:
>
> Eryk Sun added the comment:
>
>> Read the ANSI code page on Windows,
>
> I don't see why the Windows implementation is inconsistent with POSIX here.
> If it were changed to be consistent, the default encoding at startup would
> remain the same, since
On 19.03.2021 12:26, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Recently, I spent some days to document properly encodings used by Python.
Thanks for documenting this.
I would prefer to leave the locale module to really just an interface
to the lib C locale logic and not
On 19.03.2021 12:05, STINNER Victor wrote:
> I'm not sure what to do with locale.getdefaultlocale(). Should we deprecate
> it? I never used this function. How is it used? For which purpose?
>
> I undertand that in 2000, locale.getdefaultlocale() was interesting to avoid
> calling
On 19.03.2021 11:36, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> locale.getencoding()
>>
>> which interfaces to nl_langinfo(CODESET) or the Windows code
>> page and does not try to do any magic, ie. does *not* call
>> setlocale(). It needs to return what the lib C currently
On 19.03.2021 10:17, STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> I propose to add two new functions:
>
> * locale.get_locale_encoding(): it's exactly the same than
> locale.getpreferredencoding(False).
>
> * locale.get_current_locale_encoding(): always get the current
