Le mer. 21 nov. 2018 à 12:11, Antoine Pitrou <solipsis at pitrou.net> a écrit : > You mean the same API can compile to two different things depending on > a configuration? Yes, my current plan is to keep #include <Python.h> but have an opt-in define to switch to the new C API. > I expect it to be error-prone. For example, let's suppose I want to > compile in a given mode, but I also use Numpy's C API. Will the > compile mode "leak" to Numpy as well? For example, if we continue to use Py_LIMITED_API: I don't think that Numpy currently uses #ifdef Py_LIMITED_API, nor plans to do that. If we add a new define (ex: my current proof-of-concept uses Py_NEWCAPI), we can make sure that it's not already used by Numpy :-) > What if a third-party header > includes "Python.h" before I do the "#define" that's necessary? IMHO the define should be added by distutils directly, using -D <the_define_name> in compiler flags. I wouldn't suggest: #define <the_define_name> #include <Python.h> But the two APIs should diverge, so your C extension should also use a define to decide to use the old or the new API. So something will break if you mess up in the compilation :-) Victor
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