New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build _testembed on Windows #63638
Comments
Here's a patch that builds _testembed on Windows and adjusts test_capi to not skip EmbeddingTests on Windows. The .vcxproj is based on _freeze_importlib, with "when to build" settings lifted from _testimportmultiple. The patch also adjusts test_capi.EmbeddingTests.test_forced_io_encoding such that it doesn't blow up completely on Windows (and should still pass anywhere it does currently, though I haven't been able to test anywhere but on Windows yet). The test still fails, though; here's the relevant output I get: """ Traceback (most recent call last):
File "P:\Projects\OSS\Python\_cpython\lib\test\test_capi.py", line 298, in test_forced_io_encoding
self.assertEqual(out.strip(), expected_output)
AssertionError: '--- [106 chars]t: cp1252:strict\r\nstderr: cp1252:backslashre[575 chars]lace' != '--- [106 chars]t: cp437:strict\r\nstderr:
cp437:backslashrepl[571 chars]lace'
--- Use defaults Expected encoding: default
---------------------------------------------------------------------- I'm not sure whether this is a bug in the way _testembed is built or otherwise. EmbeddingTests.test_subinterps passes, though. Due to my ongoing inability to get a 64-bit build to work, this has only been tested on 32-bit Windows 7. |
Nice! I wonder if there might a difference between the default console |
That appears to be the case: """ P:\Projects\OSS\Python\cpython\ $ PCbuild\python_d.exe
Python 3.4.0a4+ (default:995173ed248a+, Nov 1 2013, 09:12:43) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys
>>> rfd, wfd = os.pipe()
>>> r = os.fdopen(rfd, 'r')
>>> w = os.fdopen(wfd, 'w')
>>> sys.stdin.encoding, sys.stdout.encoding
('cp437', 'cp437')
>>> r.encoding, w.encoding
('cp1252', 'cp1252')
""" The test passes as patched if I do 'chcp 1252' before running. Is it reasonable to patch the test to expect the default stdout and stderr encoding to equal |
This patch's changes to test_capi seem to work for Windows and keeps at least Gentoo and FreeBSD 10 happy. |
New changeset c8c6c007ade3 by Nick Coghlan in branch 'default': |
I checked that test_capi still passed on Fedora as well. Only tweak I made before committing was to ensure that the read end of the test pipe used to determine the default pipe encoding was also closed. |
New changeset 99640494ca7f by Zachary Ware in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: