Re: [pypy-dev] update (+patch) on embedding pypy
On Tue, Apr 3, 2012 at 11:32 AM, Roberto De Ioris <roberto at unbit.it> wrote:
Ok I see.
Is the rest of the API used going to be cpyext? If so, then Py_Initialize is indeed a perfect choice.
I am about to add:
Py_SetPythonHome Py_SetProgramName Py_Finalize
i will put them into
module/cpyext/src/pythonrun.c
Do you think Py_Initialize should go there too ?
-- Roberto De Ioris http://unbit.it
Sounds like a good idea. Should I merge the pull request now or wait for the others?
I think it is better to wait. Moving that to cpyext will avoid messing with translators (adding more exported symbols) too.
Ok, i am pretty satisfied with the current code (i have made a pull request).
I have implemented:
Py_Initialize Py_Finalize Py_SetPythonHome Py_SetProgramName
all as rpython-cpyext except for Py_Initialize being splitted in a c part (it requires a call to RPython_StartupCode)
Successfully tested with current uWSGI tip. Py_SetPythonHome add flawless support for virtualenv.
Great work! :) I have two questions: 1. Can other embedding c-api (e.g. PyObject_CallObject) be supported in the similar manner? 2. Can we embed multiple independent pypy? (http://bytes.com/topic/python/answers/793370-multiple-independent-python-int...) -Kibeom Kim
Hi, 2012/4/16 Kibeom Kim <kk1674@nyu.edu>
1. Can other embedding c-api (e.g. PyObject_CallObject) be supported in the similar manner?
There are already 430 functions which are already supported... PyObject_CallObject was one of the easiest. The recent developments brought the ability to start a pypy interpreter from C code.
2. Can we embed multiple independent pypy? ( http://bytes.com/topic/python/answers/793370-multiple-independent-python-int... )
Not very well, but this is also the case for CPython. Note that PyObject_CallObject for example has no context to specify which interpreter it would use; and there can only be one PyObject_CallObject function in a single executable. Why do you need independent interpreters? Would multiple threads suit your needs? -- Amaury Forgeot d'Arc
On Mon, Apr 16, 2012 at 5:03 PM, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:
Hi,
2012/4/16 Kibeom Kim <kk1674@nyu.edu>
1. Can other embedding c-api (e.g. PyObject_CallObject) be supported in the similar manner?
There are already 430 functions which are already supported... PyObject_CallObject was one of the easiest. The recent developments brought the ability to start a pypy interpreter from C code.
oh ok.
2. Can we embed multiple independent pypy?
(http://bytes.com/topic/python/answers/793370-multiple-independent-python-int...)
Not very well, but this is also the case for CPython. Note that PyObject_CallObject for example has no context to specify which interpreter it would use; and there can only be one PyObject_CallObject function in a single executable.
Why do you need independent interpreters? Would multiple threads suit your needs?
-- Amaury Forgeot d'Arc
It's not my needs, but I think that's better-designed interpreter lib. If pypy decides to support, I guess there should be two versions of api sets, one for CPython api compatibility, and the other one for multiple independent interpreter support. Py_Initialize(); Py_Initialize(PyPyInterpreter pypyinterpreter); PyObject* PyObject_CallObject(PyObject *callable_object, PyObject *args) PyObject* PyObject_CallObject(PyPyInterpreter pypyinterpreter, PyObject *callable_object, PyObject *args) But maybe no one needs it... I don't know.. -Kibeom Kim
2012/4/17 Kibeom Kim <kk1674@nyu.edu>
It's not my needs, but I think that's better-designed interpreter lib. If pypy decides to support, I guess there should be two versions of api sets, one for CPython api compatibility, and the other one for multiple independent interpreter support.
Py_Initialize(); Py_Initialize(PyPyInterpreter pypyinterpreter);
PyObject* PyObject_CallObject(PyObject *callable_object, PyObject *args) PyObject* PyObject_CallObject(PyPyInterpreter pypyinterpreter, PyObject *callable_object, PyObject *args)
But maybe no one needs it... I don't know..
This is an interesting evolution indeed; and pypy code (written in RPython) already passes a "space" object to every function. but having several object spaces in the same binary does not work at the moment. And even once this is sorted out, I think it's a bad idea to reproduce the CPython API, only to add this new parameter. I'm sure a better C API could be designed, that would integrate more easily with pypy implementation. (Use handles instead of pointers, don't expose concrete objects, etc) -- Amaury Forgeot d'Arc
participants (2)
-
Amaury Forgeot d'Arc -
Kibeom Kim