[Tim] >> Micheal Hudson made a nice start in that direction, with 2.3's [Michael Hudson] > Hey, even Tims can't spell my name right! Are you sure it wasn't your parents who screwed up here <wink>? I have a flu, and am lucky to spell anything write these dayz. My apologies to you and your parents. >> It would be a good idea to add suitable redefinitions of >> PyMODINIT_FUNC to pymemcompat.h too, but whether someone will >> volunteer to do so is an open question. > Well, I could do this in a minute, but Time's up. > (a) the file then becomes misnamed (perhaps pyapicompat.h ...) Sounds good to me. > (b) I suspect some fraction of the value of pymemcompat.h is that it > is short and has just-less-than abusive guidance on which memory > API functions to use. A new pyapicompat.h could just #include the current pymemcompat.h and a new pywhatevercompat.h. I'm not sure how easy the latter would be. The new PyAPI_FUNC(type) PyAPI_DATA(type) PyMODINIT_FUNC have snaky platform-dependent expansions, and were introduced because the older spellings were approximately incomprehensibly smushed together. Since I don't know what to do offhand if I wanted to support multiple Pythons using the current API here, I have to guess most users won't either (for example, Jim's sample docs change the last one to plain void, which isn't always right); so if you do, I believe it would be a real help.
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