> This is from tp_new and tp_dealloc, right? I think we should probably > provide assessors PyObject_Alloc and PyObject_FreeObject. Correct, and yes, that sounds like a good approach. >> - PyObject_Print is used, but can't be supported, as it uses a FILE* >> parameter > > I thought tp_print was supposed to have been removed. Yes - that should have happened for 3.0. Not sure how to deal with it now. > Anyway, if > sqlite is already using FILE *, then won't it be afflicted by the > Microsoft runtime version changes anyway? Maybe provide an extra flag > to enable FILE* APIs for those extensions that want to risk it? For the sqlite extension, that wouldn't be a problem: if they build with a different MSVC release, it will automatically link with a different CRT, which then will have a consistent set of FILE objects. The issue only arises if you pass FILE* across DLLs which in turn are linked with different CRTs. Regards, Martin
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