No good way to set 'PYTHONIOENCODING' when embedding python. #60333
Comments
|
note, I was asked to report this issue, posted on the py dev mailing list: see - http://code.activestate.com/lists/python-dev/118015/ --- We've run into an issue recently with blender3d on ms-windows where we I naively thought setting the environment variable before calling We had bug reports by windows users not able to export files because --- Of course we could distribute blender with a bat file launcher that I tried overriding the stderr & stdout, but this caused another bug on exiting, giving an assert in MSVCR90.DLL's write.c (called from python32_d.dll): import sys, io
sys.__stdout__ = sys.stdout =
io.TextIOWrapper(io.open(sys.stdout.fileno(), "wb", -1),
encoding='utf-8', errors='surrogateescape', newline="\n",
line_buffering=True)
sys.__stderr__ = sys.stderr =
io.TextIOWrapper(io.open(sys.stderr.fileno(), "wb", -1),
encoding='utf-8', errors='surrogateescape', newline="\n",
line_buffering=True)IMHO either of these solutions would be fine.
[1] http://stackoverflow.com/questions/5153547/environment-variables-are-different-for-dll-than-exe |
|
See also issue bpo-15216. |
This solution would help in many other cases as well, so adding
I think you meant Py_SetPythonHome(). Given that the IO encoding is very important for Python 3.x, a special Care must be taken, though, that the encoding cannot be set after It may overall be easier to go with the PyOS_PutEnv() solution to -- Professional Python Services directly from the Source (#1, Oct 05 2012)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
2012-09-27: Released eGenix PyRun 1.1.0 ... http://egenix.com/go35
2012-09-26: Released mxODBC.Connect 2.0.1 ... http://egenix.com/go34
2012-09-25: Released mxODBC 3.2.1 ... http://egenix.com/go33
2012-10-23: Python Meeting Duesseldorf ... 18 days to goeGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 |
|
Agree PyOS_PutEnv would be good since its not restricted to string encoding and resolves the problem of not being able to control env vars for an embedded interpreter in general. Having ways to change encoding is good too but a bit outside the scope of this report and possibly not the best solution either since its possible (through unlikely), that you need to set the encoding at the very start of python initialization- rather than site & builtin modules loads. |
|
patch attached, simply wraps putenv() |
|
At first glance your proposed fix looks like an easy hack to get around the issue. However it's not going to work properly. Embedded Python interpreters should isolate themselves from the user's environment. When IMHO we can't get around Py_GetIOEncoding(), Py_SetIOEncoding() and Py_IOEncoding. |
|
Claiming this one, mainly because I want people to largely leave the already hairy initialisation process alone until we get a chance to discuss it at the language summit next year. I plan to write up a comprehensive overview of the initialisation sequence before then, because we need to be figuring out how to *delete* code here, instead of adding even more. |
|
With the language summit passed some time ago, is there now a more clear picture of how this would fit in the initialisation process? Any idea of what a proper implementation would look like, or is the message still to wait? |
|
The gory details of the current startup situation are in PEP-432. However, the comprehensive solution described in that PEP isn't going to make it into Python 3.4, so a simpler interim fix would be worthwhile. Since Blender is designed to support building against the system Python, the trick of forcing Python to link to an alternate implementation of a function won't work. Inspired by http://docs.python.org/3/c-api/init.html#Py_SetPath, I suggest offering an API like: int Py_SetStandardStreamEncoding(char *encoding, char *errors)
{
if (Py_IsInitialized()) {
return -1;
}
Py_StandardStreamEncoding = _PyMem_Strdup(encoding);
Py_StandardStreamErrors = _PyMem_Strdup(errors);
}The initstdio function in pythonrun.c would then be updated to use the specified Py_StandardStreamEncoding and Py_StandardStreamErrors if they weren't NULL (since that would indicate an embedding application had called SetStandardStreamEncoding). |
|
Hi, Decided to give it a try and implement suggested Py_SetStandardStreamEncoding, see attached patch. A quick test with Blender under Linux (with an ASCII console) seems to work OK, unfortunatly I do not have Windows to test it where it really matters... That's my first piece of code ever written for Python, I hope it does not contain too much obvious errors! |
|
No one to check the patch? It’s rather small, should not take much time… And we really need a solution for this issue, so better to try to get this settled before 3.4 freeze! ;) |
|
Updated patch (mostly from Brecht's remarks, removed an obvious bug...) |
|
I tested the patch on Windows and can confirm it solves the problem for Blender. |
|
I added tests to the patch and tweaked a few details. Once the local test run gives it a clean bill of health, I'll commit it so it will be included in 3.4a4 this weekend and you can check it works with Blender. |
|
New changeset 9cd88b39ef62 by Nick Coghlan in branch 'default': |
|
Putting this to pending for the moment - please try it out with Blender once 3.4a4 is released, and then we'll close it. |
|
New changeset 537e13ca7683 by Nick Coghlan in branch 'default': |
|
Thanks Nick, we’ll do it for sure. :) |
|
New changeset 51480f6428a5 by Nick Coghlan in branch 'default': |
|
Buildbots weren't happy with the test case. I've done two extra commits (one to turn off the diff limit, then a second one to skip it entirely), so will hopefully be able to debug it and keep this in for the alpha. (Larry - FYI, I'll have this test fixed or the patch reverted before the alpha on the weekend) |
|
According to http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/2716/steps/test/logs/stdio, output in the subprocess was fine, but for some reason sys.stdout.encoding and sys.stderr.encoding were None in the test itself o.O |
|
Antoine pointed out this also needs a :versionadded: tag in the docs. |
|
So reusing the run command from the buildbot still passed on my system. I thought using sys.stdout.encoding (etc) would reliably get me the default IO encoding, but it appears not :( |
|
You don't want to mention the return value (-1) on error in the doc? |
|
Unfortunately the tests pass when I run them manually. On my FreeBSD |
|
On 18 Oct 2013 02:41, "STINNER Victor" <report@bugs.python.org> wrote:
I guess it should explicitly say any non-zero return value indicates an Something else occurred to me, though - this runs before Py_Initialize, and
|
|
New changeset 12d7b6171b28 by Nick Coghlan in branch 'default': |
|
I dealt with the comments folks made here and on python-dev regarding the docs and the limited API, as well as the fact it isn't safe to call PyErr_NoMemory() when this function fails. However, I still haven't been able to reproduce the failure seen on the buildbots. It isn't a simple cross-test interference problem, as I tried the randomization seed from the Ubuntu log and that still passed for me. I'm still trying the seed from Stefan's FreeBSD system, but I expect that will be clean here as well. |
|
A test order problem is indeed unlikely: I ran the tests as the buildbot user |
|
Larry - I'm kinda stumped on this one. I'm not sure how to debug the failure on the buildbots, because, as Victor said, sys.stdout/err having an encoding attribute of None *isn't* supposed to happen, so the test should be fine as it stands. And nobody has been able to reproduce the problem on a direct run. It's probably OK to leave the test disabled for the alpha (since even the failures show that *this* feature was working correctly, it was the test case itself that was breaking). While I just noticed my RHEL buildbot hit the failure as well, Stefan's inability to reproduce the problem on his FreeBSD system suggests that isn't likely to help: http://buildbot.python.org/all/builders/x86%20RHEL%206%203.x/builds/2871/steps/test/logs/stdio (And /facepalm moment, I just realised all my testing tonight has been pointless, because I forgot to remove the skip decorator from the offending test...) |
|
Ah, that got it: LC_ALL=C ./python -m test -W test_capi=> boom :) And, of course it's a StringIO object at that point... |
|
New changeset 4af20969c592 by Nick Coghlan in branch 'default': |
|
So, does that mean "asked the release manager for a ruling" is the buildbot debugging equivalent of "threatened it with tech support?" :) |
|
Bastien, did you get a chance to try embedding Python 3.4a4 in Blender yet? If that works for you, we can mark this one as closed. |
|
Wow… Good thing you remind me that. Just tested it here (linux with ASCII terminal), works perfectly. Thanks again for all the integration work, Nick! |
|
Excellent! Zachary Ware got the embedding tests running and passing on Windows in bpo-19439 (previously they were only executed on *nix systems), so Python 3.4 should resolve this problem on all platforms. |
|
New changeset 4cd620d8c3f6 by R David Murray 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: