1. PyPy
  2. PyPy project
  3. pypy
  4. Pull requests

Pull requests

#67 Declined
Deleted repository
default (7eb44aa590a2)

added implementation of Py_Initialize,Py_Finalize,Py_SetPythonHome,Py_SetProgramName as cpyext

  1. Roberto De Ioris

This commit add support for a series o cpython-compatible api functions required for embedding libpypy in c apps. They are all written in rpython (as cpyext) except for Py_Initialize requiring a call to RPython_StartupCode. Tested with uWSGI tip.

Comments (7)

  1. Amaury Forgeot d'Arc

    Very nice! Especially for the RPython implementation of PyPy_Initialize().

    Do the cpyext unit tests still pass? I suspect that RPython_StartupCode is not defined in the C stub library we compile for testing cpyext with an interpreted pypy.

    1. Roberto De Ioris author

      would be great to reuse that code, but i think both will require refactoring to support PYTHONHOME env var and custom sys.prefix (required by Py_SetPythonHome)

      1. Amaury Forgeot d'Arc

        I'm OK to leave it simple to begin with; but pypy.file will hardcode the path of the pypy source tree, at translation time. Is sys.path correctly set if one donwloads the nightly builds and unpack it anywhere? Should the code use sys.executable somehow?

        1. Roberto De Ioris author

          honestly it is not clear to me how to make 'srcdir' independent from pypy.file Apps embeding python normally set sys.executable to their binary path, so following that value could lead to problems. Maybe we could take the absolute path of libpypy-c with dladdr() trick, but this is glibc specific.

          1. Amaury Forgeot d'Arc

            You are right of course. I did embed a Python interpreter several times, but I forgot that PythonHome and Path should almost always be overridden. Since pypy does not use sys.prefix, defaulting to the original source path is the right thing to do.