2017-08-31 18:51 GMT+09:00 Nick Coghlan <ncoghlan at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170831/b6e275d8/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4