This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients eric.snow, htgoebel, ncoghlan, vstinner
Date 2018-03-15.11:01:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1521111669.82.0.467229070634.issue33042@psf.upfronthosting.co.za>
In-reply-to
Content
Patched test_capi results for 2ebc5ce42a8a9e047e790aefbf9a94811569b2b6 (the global state consolidation commit): both pre-initialization tests fail

Patched test_capi results for bab21faded31c70b142776b9a6075a4cda055d7f (the immediately preceding commit): both pre-initialization tests pass

Ding, ding, ding, we have a winner :)

Rather than reverting the options-related aspects of that change though, I think a nicer way to handle it will be to add a "pre-init fallback" path to those functions that stores the raw wchar_t data, and postpones converting those values to Py_Unicode objects until we need them in _PyInitialize_Core.

I'm not sure what to do about PySys_AddWarnOptionUnicode though: I think that's just outright incoherent as an API, since you need to call it before Py_Initialize for it to do anything useful, but we don't support calling any of the Unicode creation APIs until *after* Py_Initialize.
History
Date User Action Args
2018-03-15 11:01:09ncoghlansetrecipients: + ncoghlan, htgoebel, vstinner, eric.snow
2018-03-15 11:01:09ncoghlansetmessageid: <1521111669.82.0.467229070634.issue33042@psf.upfronthosting.co.za>
2018-03-15 11:01:09ncoghlanlinkissue33042 messages
2018-03-15 11:01:09ncoghlancreate