<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">Uno dei punti di forza di python (secondo me) e' la gigantesca</span><br>
</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
disponibilita' di moduli, e un utente medio si aspetta di poter continuare<br>
a usarli tutti senza problemi, soprattutto se NON gli comunichi a<br>
caratteri cubitali tutte le implicazioni del non-blocking (e invece gli<br>
porti solo i vantaggi</blockquote><div>ecco, io rientro nella categoria utente medio XD un po per colpa mia un po perché non ho mai avuto la necessità del "NON-BLOCKING" e non mi ero interessato della cosa.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Detto questo, ci sono comunque diversi moduli</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

async-friendly/tornado-friendly ma sono spesso "progettini", a volte<br>
sviluppati senza l'attenzione necessaria ad un modulo db-adapter (vedere<br>
il lavoro titanico che c'e' dietro a psycopg2, che per la cronaca puo'<br>
essere adattato al non-blocking</blockquote><div>per psycopg2 ho visto che esiste momoko(come sugerito da Dario) però mi sono accorto che in realtà non ti risolve del tutto il problema perché alla fine sei vincolato alla dimensione del connection pool.</div>
<div><br></div></div></div></div>