Uso de scipy.stats.stats en django después de la implementación

Question

Estoy en el proceso de crear una interfaz django-powered (1.3) para un paquete que se basa en gran medida en scipy.stats.stats (versión scipy 0.9.0), llamado ovl . Durante las primeras fases de desarrollo, utilizando el propio servidor de desarrollo de djangos, esto no fue un problema. Después del despliegue utilizando apache debian/2.2.9 y mod_wsgi 3.3, esto causa un problema grave.

Cualquier vista que intente cargar en el navegador, comienza a cargarse, y sigue haciéndolo durante unos 5 minutos (hasta el tiempo de espera) y aparece una página de 500. Solo importa trabajos scipy, pero no hace que scipy.stats.stats o incluso scipy.stats estén disponibles. Esto no es sorpresa; en la documentación en scipy's init .py se indica que el subpaquete stats debe importarse explícitamente. Sin embargo, lo mismo se dice sobre el subpaquete cluster, que importa en django (de la web y en el django-shell) sin ningún problema y aparece en dir(scipy), que no en un ipython (0,10 .2) -session, donde simplemente no aparece, como esperaba.

En el comando dir(scipy); devuelve resultados diferentes cuando proviene de la web (una lista de 568 cadenas, incluido el subpaquete cluster) en el shell ipython normal (564 cadenas, sin subpaquete cluster) y sorpresa, sorpresa, en el shell django. En django shell scipy tiene 570 atributos, incluidos los paquetes cluster y stats.

Otra cosa es, si sigo importando el paquete ovl, mientras mantengo las importaciones de scipy.stats a cierta distancia (no en uno de los archivos de la aplicación), a veces recibo un error de ViewDoesNotExist que indica que no hay índice de método en el módulo de vistas mientras que claramente hay uno. Lo que me recuerda a this.

Así que ahora estoy pensando en estas soluciones en lugar feos:

init del
• Edición scipy para importar el paquete de estadísticas por lo que parece 'normalmente' en dir (scipy) y es accesible a través scipy.stats y yo puede usar el código anterior
• Arrebatando sub-paquete de estadísticas de scipy y hacer un paquete normal fuera de él (tal vez mediante un enlace simbólico)

Soy reacio en la aplicación de estas soluciones, sin embargo. El grupo de hechos aparece en scipy en un entorno django me preocupa un poco. Pensé que tal vez esto tiene algo que ver con ser usuario de www-data al iniciar sesión en la web, pero no sé cómo verificarlo.

¿Alguien más se encontró con esto? Partes de esto? ¿O pensamientos útiles?

Oh y otra implementación de django funciona.

Answer 1

mod_python solía intentar usar varios intérpretes de Python en el mismo proceso. mod_wsgi podría estar haciendo lo mismo. Si bien esto funciona bien con frecuencia, algunos módulos de extensión no son compatibles. scipy.stats probablemente esté importando dicho módulo de extensión. Hemos tenido informes similares en la lista de correo scipy sobre scipy.stats en mod_python. Consulte la documentación de mod_wsgi para ver si puede configurarlo de modo que no use varios intérpretes en el mismo proceso o encuentre una estrategia de implementación diferente que use un intérprete por proceso para la aplicación.

Answer 2

También encuentro este problema cuando uso scipy.stats en mi aplicación django. En el entorno django manage.py runsever, mi aplicación se ejecuta correctamente sin ningún problema. Pero cuando despliego la aplicación al servidor Apache con mod_python, no puedo ingresar a mi aplicación, y el navegador continúa cargando hasta el tiempo de espera. Después de eliminar todas las declaraciones importadas de scipy.stats en mi aplicación, el problema está resuelto y puedo ejecutar mi aplicación en el servidor apache.