Marc Recht <recht at netbsd.org> writes: > That's why I'm totaly in favor of "stricly POSIX conforming" for > Python itself. It's IMHO an other situation when it comes to modules > or extensions. (Also, the ones in the Python distribution.) IMHO the > module implementors should define for themself which standard they > need/support (if any). As you've pointed out in your last mail there > are (major?) technical problems with stat (eg. struct stat) which need > to be solved. Unfortunately, it might just be that this specific problem cannot be solved, in a general way. Instead, the author of the code would have to take the risk of breaking the in-process ABI. For example, if the #defines would cause different libraries to be linked (rather than different symbols of the same library being used), you might find that mapping both libraries into the same process is just not supported, and that the extension module would still get the POSIX version of the function at run-time, and that the system vendor provides no support for "mixed" processes. So if you implement such a change, you should also make it easy for a developer to avoid the danger of such undeliberate breakage, by having a mode where extensions compile with the exact same settings as the main interpreter. Perhaps that should even be the default, and the do-it-yourself configuration would be activated only on explicit request (e.g. a define before including Python.h). 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