Utilizzo di scipy.stats.stats in django dopo la distribuzione

Question

Sono in procinto di creare un'interfaccia django-powered (1.3) in un pacchetto che fa molto affidamento su scipy.stats.stats (scipy versione 0.9.0), chiamato ovl . Durante le prime fasi di sviluppo, utilizzando il proprio server di sviluppo djangos, questo non rappresentava un problema. Dopo la distribuzione con apache debian/2.2.9 e mod_wsgi 3.3, questo causa un problema serio.

Qualsiasi sia la vista che sto tentando di caricare nel browser, inizia il caricamento e continua a farlo per 5 minuti (fino al timeout) e viene visualizzata una pagina di 500. Basta importare lavori scipy ma, fa non rendere scipy.stats.stats o anche scipy.stats disponibili. Questa non è una sorpresa; nella documentazione in scipy init .py si afferma che il subpackage stats deve essere importato in modo esplicito. Tuttavia, lo stesso si dice sul subpackage cluster, che importa in django (dal web e nel django-shell) senza alcun problema e in effetti compare in dir(scipy), che non è in un ipython (0.10 .2) -sessione, dove non si presenta, come mi aspettavo.

Al comando dir(scipy); restituisce risultati diversi quando proviene dal web (una lista di 568 stringhe, incluso il subpackage cluster) nella normale shell ipython (stringhe 564, senza subpackage cluster) e sorpresa, sorpresa, nella shell django. Nella shell django scipy ha 570 attributi, inclusi entrambi i pacchetti cluster e stats.

Un'altra cosa è, se continuo a importare il ovl -package, pur mantenendo le importazioni scipy.stats ad un po 'di distanza (non in uno dei file della applicazione stessa), a volte ottengo un errore che indica ViewDoesNotExist che non c'è alcun indice di metodo nel modulo delle viste mentre ce n'è uno chiaramente. Che mi ricorda this.

Così ora sto pensando di queste piuttosto brutti soluzioni:

init di
• Editing SciPy per importare il pacchetto di statistiche in modo che appaia 'normalmente' a dir (SciPy) ed è accessibile attraverso scipy.stats ed io può usare il vecchio codice.
• Afferrando stat subpackage di SciPy e fare un pacchetto normale fuori di esso (magari utilizzando un link simbolico)

sono riluttante nell'applicazione di queste soluzioni, tuttavia. Il cluster di fatto si presenta in scipy in un ambiente di Django mi preoccupa un po '. Ho pensato che forse questo ha qualcosa a che fare con l'essere utente di www-data quando accedono dal web, ma non so come controllarlo.

Qualcun altro l'ha incontrato? Parti di questo? O altrimenti pensieri utili?

Oh e un'altra distribuzione di django funziona.

Answer 1

mod_python utilizzato per provare a utilizzare più interpreti Python nello stesso processo. mod_wsgi potrebbe fare lo stesso. Mentre questo spesso funziona bene, alcuni moduli di estensione non supportano questo. scipy.stats sta probabilmente importando un modulo di estensione di questo tipo. Abbiamo avuto rapporti simili sulla mailing list scipy riguardante scipy.stats sotto mod_python. Controlla la documentazione di mod_wsgi per verificare se è possibile configurarlo in modo che non utilizzi più interpreti nello stesso processo o trovare una strategia di distribuzione diversa che utilizza un interprete per processo per l'app.

Answer 2

Ho riscontrato questo problema anche quando uso scipy.stats nella mia applicazione django. In django manage.py ambiente runever, la mia app viene eseguita correttamente senza alcun problema. Ma quando installo l'app sul server Apache con mod_python, non posso accedere alla mia app e il browser continua a caricarsi fino al timeout. Dopo aver rimosso tutte le istruzioni scipy.stats importate nella mia app, il problema è risolto e posso eseguire la mia app nel server Apache.