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(). The origin of the output being checked is https://hg.python.org/cpython/file/default/Programs/_testembed.c#l79 Note the mixture of output from C level printf() calls and Python level print() calls inside check_stdio_details(). 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 is only the lines that start with "Expected" that end with '\n' rather than '\r\n' under VC14 (those are the ones produced directly from C - the others are produced via Python's print builtin). If that *is* what's happening, we may want to convert the embedding tests over to running the subprocess in universal newlines mode, and adjust the expected output accordingly. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22731> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
