> On Apr 13, 2020, at 5:25 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > > On a related but different note, what is the recommended policy > (assuming it's not to use the C API) for embedding Python, and for > exposing the embedding app to Python as a C extension? My standard > example of this is the Vim interface to Python - see > https://github.com/vim/vim/blob/master/src/if_python3.c > <https://github.com/vim/vim/blob/master/src/if_python3.c>. I originally > wrote this back in the Python 1.5 days, so it's *very* old, and quite > likely not how I'd write it now, even using the C API. But what's the > recommendation for code like that in the face of these changes, and > the suggestion that using 3rd party tools is the normal way to write C > extensions?
I’d like to +1 this request for a standard for embedding Python while at the same time exposing the embedding app to Python as a C extension. We do something remarkably similar to Vim here (along with other files in the same directory). https://github.com/nion-software/nionui-tool/blob/master/launcher/PythonStubs.cpp <https://github.com/nion-software/nionui-tool/blob/master/launcher/PythonStubs.cpp> I’ve looked into cffi but it seems to only solve a fraction of the problem. Our Qt-based application embeds Python and provides callbacks from Python to our application. It runs on macOS, Linux, and Windows and runs unchanged on Python 3.6, 3.7, and 3.8 since it dynamically links to Python.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5RMFHARU7AY5TY7TKU356UTNHCLYBDYB/ Code of Conduct: http://python.org/psf/codeofconduct/
