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 vstinner
Recipients eric.snow, lukasz.langa, ncoghlan, vstinner
Date 2018-11-18.22:48:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1542581300.48.0.788709270274.issue35266@psf.upfronthosting.co.za>
In-reply-to
Content
> I like where you're going with this, but would be willing to write an update to PEP 432 to sketch out in advance what you now think the end state is going to look like?

Sadly, I'm unable to design in advance what will be the final state.

Python initialization is a giant beast, full of traps, with many practical issues.

I'm moving slowly, step by step.

For example, this issue "only" move wchar_t* out of _PyCoreConfig, but Eric Snow told that me that he (or you, Nick, I don't recall) would prefer to not use "Unicode" during the very first initialization stage. wchar_t* is already Unicode. I'm unable to see yet how to have 3 stages:

1) no unicode
2) C structures, wchar_t*
3) Python objects

Currently, (1)+(2) is _PyCoreConfig and (3) is _PyMainInterpreterConfig.

I prefer to work directly on the code to make sure to have a working implementation, than working on paper but don't know if it's possible to implement it :-)

One issue is that it requires more steps, but from my point of view we better control the risk since it's possible to move back if we make a mistake in a small change.
History
Date User Action Args
2018-11-18 22:48:20vstinnersetrecipients: + vstinner, ncoghlan, lukasz.langa, eric.snow
2018-11-18 22:48:20vstinnersetmessageid: <1542581300.48.0.788709270274.issue35266@psf.upfronthosting.co.za>
2018-11-18 22:48:20vstinnerlinkissue35266 messages
2018-11-18 22:48:20vstinnercreate