On Fri, Nov 11, 2022 at 8:16 PM Eryk Sun wrote:
> If sys.std* are console files, then in Python 3.6+, sys.std*.buffer.raw will
> be _io._WindowsConsoleIO
> io.TextIOWrapper uses locale.getpreferredencoding(False) as the default
> encoding
Thank you for your replies - checking the sys.stdout.buf
On Sat, Nov 12, 2022 at 11:53 AM Inada Naoki wrote:
>
> On Sat, Nov 12, 2022 at 10:21 AM 12Jessicasmith34
> <12jessicasmit...@gmail.com> wrote:
> >
> >
> > Two questions: any idea why this would be happening in this situation?
> > AFAIK, stdout *is* a console when these images are running the pyt
On Sat, Nov 12, 2022 at 10:21 AM 12Jessicasmith34
<12jessicasmit...@gmail.com> wrote:
>
>
> Two questions: any idea why this would be happening in this situation? AFAIK,
> stdout *is* a console when these images are running the python process.
> Second - is there a way I can check the locale and
On 11/11/22, 12Jessicasmith34 <12jessicasmit...@gmail.com> wrote:
>
> any idea why this would be happening in this situation? AFAIK, stdout
> *is* a console when these images are running the python process.
If sys.std* are console files, then in Python 3.6+,
sys.std*.buffer.raw will be _io._Window
> If stdout isn't a console (e.g. a pipe), it defaults to using the
process code page (i.e. CP_ACP), such as legacy code page 1252
(extended Latin-1).
First off, really helpful information, thank you. That was the exact background
I was missing.
Two questions: any idea why this
On 11/10/22, Jessica Smith <12jessicasmit...@gmail.com> wrote:
>
> Weird issue I've found on Windows images in Azure Devops Pipelines and
> Github actions. Printing Unicode characters fails on these images because,
> for some reason, the encoding is mapped to cp1252. What is particularly
> weird ab
