Message306938
| Author | ncoghlan |
|---|
| Recipients | Decorater, eric.snow, ncoghlan, serhiy.storchaka, vstinner |
|---|
| Date | 2017-11-25.03:45:38 |
|---|
| SpamBayes Score | -1.0 |
|---|
| Marked as misclassified | Yes |
|---|
| Message-id | <1511581539.67.0.213398074469.issue32096@psf.upfronthosting.co.za> |
|---|
| In-reply-to | |
|---|
| Content |
|---|
Huh, those crashes are interesting - I'd guess that it means we have a platform-dependent dependency from Py_DecodeLocale on to Py_SetPythonHome in order to locate the encodings module. If I'm right, that dependency would then mean that embedding applications can only rely on Py_DecodeLocale to do "char *" to "wchar_t *" conversions if they can also rely on the locale encoding always being a builtin one that bypasses the search for the encodings module.Perhaps we should be recommending temporarily doing 'setenv("PYTHONHOME", home)' (and then reverting that after calling Py_Initialize so it doesn't get inherited by subprocesses) as the preferred approach to handling platforms with "char *" based native filesystem APIs, and adding such a setting to that particular `_testembed` test? |
|