Use Py_LIMITED_API #371
Open
Use Py_LIMITED_API #371
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closed
Add dependency on stock sip so pip will install it. Update sip to version 4.19.2.
… it, and using the stuff from the rest of Phoenix. Lots more still to go...
and adding wxPy APIs for things not supported by Py_LIMITED_API
RobinD42
force-pushed
the
py-limited-api
branch
from
8e9ac2d
to
3e2f35d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
VERY early look at using the Py_LIMITED_API which, in theory, would allow us to have one binary that works with multiple Python 3.x versions. See also #314 and https://www.python.org/dev/peps/pep-0384/.
It looks like there will be lots of flaming hoops to jump through to make it work, and I'm not certain that it is even possible at all due to the kinds of Python C API things we're already using that are not available in the Python limited API. For example, all the
PyFoo_GET_ITEMtype of "faster" macros will need to be changed to their function call equivalents, all operations on buffer objects, Python datetime objects, PyMethods and probably some others are not allowed. And so on...I can do like PyQt/SIP has done and make a separate wxpy_api extension module that is built for each version of Python, and exports an API that can be used by the Python3-generic binaries for things that can't be done with the limited API. I've started doing that, but it's still unclear whether that will be sufficient for all the things that will need to change. And, of course, that means that a new package will need to be built and distributed, dependencies tracked, etc.
Also unclear at this point is whether it will be possible to include support for Python3.4 on Windows since it uses a different version of the compiler than the newer 3.x versions do.