carga archivos pyd desde un zip desde python incrustado

Puedo cargar módulos de Python (.py, .pyc, .pyd) desde un archivo zip llamando a “import some_module” desde un intérprete de Python solo después de que sys.path se haya extendido para incluir el archivo zip y solo después de haber ejecutado

import zipextimporter zipextimporter.install() 

Esto último es requerido para los módulos .pyd.

También puedo cargar los módulos .py y .pyc de Python desde Python incrustado en C ++. Sin embargo, para cargar también módulos .pyd desde Python incrustado, agregué

 PyRun_SimpleString("import zipextimporter"); 

El exe de C ++ se ejecuta más allá de esta línea sin error. Pero el siguiente comando

 PyRun_SimpleString("zipextimporter.install()"); 

me da este error

introduzca la descripción de la imagen aquí

¿Por qué zipextimporter.install () se bloquea cuando Python está incrustado?

¿Como puedo resolver esto?

¿Acaso tiene que ver con la forma en que se comstack el código C ++? Yo uso g ++:

g++ embed-simple.cpp -IE:\Python27\include -LE:\Python27\libs -lpython27 -o embed-simple

Vi un enlace ¿Cómo enlazar contra msvcr90.dll con mingw gcc?

¿Podría eso proporcionar una solución? En caso afirmativo, ¿cómo debería ajustarlo, gcc -> g ++, ya que estoy ejecutando el código C ++, no C.

Estoy ejecutando Python 2.7.2 en WinXP.

No obtengo el error de tiempo de ejecución después de una instalación limpia de Python 2.7.2, solo esto:

Error de importación: ningún módulo llamado ….

¿Importaría la forma en que se comstack el script C ++ incrustado? Utilicé g ++. También compilé con el comstackdor de Intel, pero eso dio el mismo error de tiempo de ejecución. Tal vez debería probar MS Visual C ++.

¿O usar ctypes para importar el pyd?

memimporter y zipextimporter pueden cargar archivos .pyd desde la memoria / archivos zip sin descomprimirlos en archivos.

El runtimerror R6034 se debe al hecho de que la biblioteca de tiempo de ejecución de VC9 se debe cargar a través de un manifiesto. Ejecutar su código en Python 2.5, que utiliza un tiempo de ejecución de C diferente, lo más probable es que tenga éxito. Supongo que debe incrustar un manifiesto que haga referencia a la biblioteca de tiempo de ejecución de VC9 en su exe; tal vez el wiki py2exe puede proporcionar alguna orientación.

Los archivos PYD son archivos DLL nativos con extensión renombrada. Cargarlos depende de las instalaciones del sistema operativo y las restricciones del sistema operativo.

Por lo que sé, Windows XP, o cualquier otro sistema operativo, no puede cargar archivos DLL desde archivos ZIP, por lo que no puede cargar archivos PYD desde archivos ZIP.

¿Para qué versión de python se compiló memimporter.pyd (que está dentro del zipextimporter)? Si el intérprete de python y pyd no coinciden, obtendrá choques horribles.

No estoy seguro de dónde está el código del importador mem, pero supongo que creo que la idea es insertar un enlace de importación que detecte una importación de pyd basada en zip y extraiga el pyd a una ubicación temporal y llame al estándar del intérprete de Python importar en eso.

Esto suena como el mismo tipo de problemas que tuve al intentar comstackr una aplicación con py2exe. vea aquí: http://www.py2exe.org/index.cgi/Tutorial , vea la sección 5.2. Lo mismo sucede … la primera vez que intenta usar memimporter, se bloquea con un mensaje de error similar. Básicamente, para Python 2.6+ necesita tener la versión exacta de la biblioteca de tiempo de ejecución en la ruta y un manifiesto que apunte a ella. Ya que estás usando Python incrustado, no sé cómo funciona todo, pero tal vez eso te acerque más.

Comenzaría por poner la versión ‘correcta’ de la dll de tiempo de ejecución en algún lugar, y en su código de Python, antes de importar zipextimporter, agregue la ruta del tiempo de ejecución correcto a sys.path y vea si eso lo corrige. aunque no estoy seguro de cómo se obtiene el manifiesto allí para un python incrustado. Es posible que deba incluirse en el manifiesto de la aplicación para padres.

Edición: Por cierto, lo olvidé, también encontramos otra forma de solucionar este problema. Olvidé los detalles exactos, pero lo que sucede es que tu aplicación carga la versión predeterminada del tiempo de ejecución, y luego Python pregunta por su versión y encuentra una en c: \ python {26,27} y no coincide. La forma más sencilla de resolver este problema es eliminar c: \ python \ msvcr90.dll. Entonces, python no llegará a la versión local (antigua) de la dll que podría no funcionar con el manifiesto de su aplicación, y ambas tendrán que salir y obtener la versión actual del directorio de Windows, que coincidirá.