2017-08-31 18:51 GMT+09:00 Nick Coghlan <ncogh...@gmail.com>: > [...] > I think that's just a bug in the startup refactoring - we don't > currently test the "Py_Initialize()/Py_Initialize()/Py_Finalize()" > sequence anywhere, and I'd missed that it's explicitly documented as > being permitted. I'd still want to keep the "multiple calls without an > intervening finalize are prohibited" behaviour for the new more > granular APIs (since it's simpler and easier to explain if it just > always fails rather than attempting to check that the previous > initialization supplied the same config settings), but the documented > Py_Initialize() behaviour can be reinstated by restoring the early > return in _Py_InitializeEx_Private. > I get the point of difference between document and current code, I don't mind :)
As far as the PEP itself goes, this version looks good to me, so if > there aren't any other significant comments between now and then, I'm > likely to accept it at the core development sprint next week. > I took time, but I'm happy to near to finish. Thanks you for helping! Masayuki
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
