[issue16587] Py_Initialize breaks wprintf on Windows

Markus Kettunen added the comment: > On Linux, std::wcout doesn't use wprintf(). Do you mean that std::wcout also > depends on the "mode" of stdout (_setmode)? Yes, exactly. I originally noticed this bug by using std::wcout on Windows. -- ___ Python

[issue16587] Py_Initialize breaks wprintf on Windows

STINNER Victor added the comment: "In C++ this often means using std::wstring and std::wcout. Maybe these are more common than wprintf? In any case the console output breaks as Py_Initialize hijacks the host application's standard output streams which sounds quite illegitimate to me." On Linu

[issue16587] Py_Initialize breaks wprintf on Windows

Markus Kettunen added the comment: It's quite common to use wide character strings to support Unicode in C and C++. In C++ this often means using std::wstring and std::wcout. Maybe these are more common than wprintf? In any case the console output breaks as Py_Initialize hijacks the host appli

[issue16587] Py_Initialize breaks wprintf on Windows

STINNER Victor added the comment: If I understood correctly, supporting the "wide mode" for wprintf() requires to modify all calls to functions like printf() in Python and so it requires to change a lot of code. Since this issue was the first time that I heard about wprintf(), I don't think th

[issue16587] Py_Initialize breaks wprintf on Windows

Mark Lawrence added the comment: I'll let our Windows gurus fight over who gets this one :) -- nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware ___ Python tracker ___ _

[issue16587] Py_Initialize breaks wprintf on Windows

John Ehresman added the comment: One way to fix this is to use the FileRead & FileWrite api functions directly as proposed in issue 17723 I would regard this as a change in behavior and not a simple bug fix because there is probably code written for 3.3 that assumes the C level stdout is in b

[issue16587] Py_Initialize breaks wprintf on Windows

STINNER Victor added the comment: > _setmode(self->fd, O_BINARY) change was done in Python 3.2: see the issue > #10841 The main reason was to be able to read binary file from sys.stdin using the CGI module: see the issue #4953. In _O_TEXT mode, 0x0A byte is replaced with 0x0A 0x0D (or the oppos

[issue16587] Py_Initialize breaks wprintf on Windows

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue16587] Py_Initialize breaks wprintf on Windows

STINNER Victor added the comment: _setmode(self->fd, O_BINARY) change was done in Python 3.2: see the issue #10841. This change introduced regressions: - #11272: "input() has trailing carriage return on windows", fixed in Python 3.2.1 - #11395: "print(s) fails on Windows with long strings",

[issue16587] Py_Initialize breaks wprintf on Windows

Changes by Antoine Pitrou : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue16587] Py_Initialize breaks wprintf on Windows

Markus Kettunen added the comment: If the standard streams are not used through Python, this hack can be used to work around the bug on C side: #ifdef WIN32 #include #endif ... Py_Initialize(); #ifdef WIN32 _setmode(stdin->_file, O_TEXT); _setmode(stdout->_file, O_TEXT); _setmode(stderr->_f

[issue16587] Py_Initialize breaks wprintf on Windows

New submission from Markus Kettunen: In a C application on Windows, at least on MSVC 2010 and Windows 7, do this: wprintf(L"Test\n"); Py_Initialize(); wprintf(L"Test\n"); Output is: Test T e s t I was able to track the issue to fileio.c to the following code block by searching where wprintf