>>> 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-interpreters-c-c-program) -Kibeom Kim _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev