Roundup Robot added the comment:
New changeset b31e803d5ad3 by Steve Dower in branch '3.5':
Closes #22731: Documents change of console mode.
https://hg.python.org/cpython/rev/b31e803d5ad3
New changeset e93a8088a1f9 by Steve Dower in branch 'default':
Closes #22731: Documents change of console
Changes by Steve Dower steve.do...@microsoft.com:
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22731
___
Roundup Robot added the comment:
New changeset edb270e5c9c3 by Steve Dower in branch 'default':
#22731 test_capi test fails because of mismatched newlines
https://hg.python.org/cpython/rev/edb270e5c9c3
--
nosy: +python-dev
___
Python tracker
Steve Dower added the comment:
As near as I can tell, Py_Initialize() is causing the stdout mode to change
from O_TEXT to O_BINARY in _testembed.
Looking at the output in this test, you can see the first printf('\n') (after
'Use defaults') is correctly translated, but the next '\n' comes
Nick Coghlan added the comment:
Yes, switching the subprocess invocation in test_capi.py to universal newlines
mode and joining the expected output with '\n' sounds like the right test case
fix to me.
As far as the printf() change goes, I'm not really the right person to ask -
all my Windows
Nick Coghlan added the comment:
One last thing: we may also want to update the C API docs to explicitly point
out the discrepancy in handling of '\n' on Windows between printf() in VC14+
(which no longer does the '\r\n' substitution) and the print functions in the
Python C API (which will
R. David Murray added the comment:
That information should also go in the porting notes section of the 3.5 What's
New, but clearly labeled (if I understand correctly) as applying only to
applications that embed python on Windows.
--
___
Python
Steve Dower added the comment:
I think it's also in any extension that prints directly to the console without
going through the Python IO machinery.
I'll make the test change in default, since that's what the os.linesep is
trying to achieve anyway, and modify the porting notes in my branch,
Nick Coghlan added the comment:
Argh, you're making me page _testembed back into my brain. I try to avoid
having to do that ;)
Anyway, this doesn't look like the right fix to me - although it may indeed be
a test bug uncovered by a VC10-VC14 behavioural change in the behaviour of
printf().
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22731
___
___
Python-bugs-list
Steve Dower added the comment:
Argh, you're making me page _testembed back into my brain. I try to avoid
having to do that ;)
Hehe, sorry.
My guess would be that VC10 is translating '\n' to '\r\n' in the
printf() calls, and VC14 has stopped doing that.
To confirm my theory: check if it
New submission from Steve Dower:
The test_capi.test_forced_io_encoding test currently requires that newlines
match when checking the results. This apparently does not occur with VC10
builds, but does appear with newer versions of the compiler.
This patch normalises the line endings in the
R. David Murray added the comment:
I don't understand why this patch is necessary. The test already joins the
expected output with os.linesep (and doesn't test against err, that's just for
verbose informational purposes). Are you saying that the generated output is
not using os.linesep? In
Steve Dower added the comment:
The generated output is using os.linesep, but the result from
run_embedded_interpreter() is not.
I assume there's a difference (fix) in MSVCRT between VC10 and VC12 (maybe VC11
- didn't test) that causes '\n' to flow through Popen.communicate() where it
R. David Murray added the comment:
That's my point. What comes out of communicate *should* be os.linesep, unless
I'm missing something. So this test failing indicates a bug. Of course, I've
never worked with an embedded interpreter, so there could be something I'm
missing. But, you say
15 matches
Mail list logo
