<div dir="ltr"><div><div><div><div>ciao Enrico,<br></div>grazie delle risposte<br><br></div>in realtà volevo fare alcuni esempi random su tecniche un po' esoteriche rispetto al mio operare corrente<br></div>nel mio lavoro di ogni giorno cerco di mantenermi molto KISS<br></div>poi arrivano i talk di pycon, ti aprono un po' le vedute e finisci a volte per riconsiderare pattern o tecnologie che normalmente lascierei un po' nel cassetto o in backlog<br><br><br><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 20 aprile 2015 18:56, enrico franchi <span dir="ltr"><<a href="mailto:enrico.franchi@gmail.com" target="_blank">enrico.franchi@gmail.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-04-20 14:50 GMT+01:00 Marco De Paoli <span dir="ltr"><<a href="mailto:depaolim@gmail.com" target="_blank">depaolim@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>1. potrei farlo con una meta classe<br></div></blockquote><div><br></div></span><div>Pessima idea. Ci sono casi in cui le meta-classi sono il sistema piu' rapido e robusto per avere una certa cosa. In generale sono un overkill. In generale, non sono la soluzione giusta.</div></div></div></div></blockquote><div><br></div><div>concordo, nei casi in cui ho visto usare una metaclasse la soluzione adottata non mi è piaciuta molto<br></div><div>l'ultimo in ordine di tempo mi è successo con djangorestframework: in base ad un parametro many=True mi istanziava "a mia insaputa" una classe wrapper che conteneva la mia<br></div><div>Questo significava che non avevo alcun modo semplice per fare l'override/plug<br></div><div>Insomma, mi sono convinto che il principio stesso che "può succedere di chiamare il costruttore di una classe ma qualcuno (presumibilmente per il tuo bene) decide di restituirtene un altra", beh, non mi piace granchè<br></div><div>In questi casi tendo ad usare una funzione che faccia da Factory<br></div><div>Sarò pure meno cool, ma preferisco essere più esplicito e comprensibile<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div><div>2. potrei inserire un server tornado giusto "per non si sa mai"<br></div></blockquote><div><br></div></span><div>Non lo farei. Uno strato di architettura "per non si sa mai" e' comunque uno strato di architettura che si puo' rompere domani prima di avere provveduto ad un qualunque beneficio per il customer.</div></div></div></div></blockquote><div><br></div><div>Sì, perfettamente daccordo. Il <span class="">"per non si sa mai" era una battuta<br></span></div><div><span class="">Al momento non alcun motivo valido per scomodare Tornado nei miei progetti: Django con i worker uWSGI mi vanno benissimo<br></span></div><div><span class="">Non uso websockets o roba simile per cui sopravvivo benissimo<br></span></div><div><span class="">Diciamo che ho risentito parlare di Tornado con asyncio e la prima domanda da nerd è "datemi un occasione per giocarci, se non me la date me la invento!"<br></span></div><div><span class="">Poi però mi sono calmato e sono tornato ad occuparmi di importazioni di file Excel ;-)<br></span></div><div><span class=""><br></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div><div>4. dovrei usare pytest e rifattorizzare tutti i setUp/tearDown del mio progetto<br></div></blockquote><div><br></div></span><div>Questa invece e' una buona idea. Cioe'... rifattorizzare tutto non necessariamente lo e'. Ma cominciare ad usare PyTest lo e'.</div></div></div></div></blockquote><div><br></div><div>Il talk di Simone Dalla mi ha in effetti convinto a provarlo il prima possibile<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Tipo una volta mi venne la balzana idea di convertire tutta una test-suite da nose a py.test; ora, i test vennero meglio, piu' chiari piu' robusti. Ci persi un monte di tempo. Adesso quando devo lavorare ad un progetto con test nose (o unittest) la mia policy e':</div><div><br></div><div>1. continuo a scrivere nose(unittest) finche' non ho un buon motivo</div><div>2. scrivo la parte con il buon motivo con py.test</div><div>3. a tempo morto riguardo i test, butto nel cesso i test vecchi e poco significativi (cosa che fa bene comunque), cerco di individuare dei pattern che beneficiano davvero di py.test e riscrivo quelli, un po' per volta.</div><div>4. ogni volta che tocco qualche test specifico, lo riscrivo con py.test (ma solo dopo che il procedimento di introduzione di py.test e' iniziato, motivato da una necessita' oggettiva).</div></div></div></div></blockquote><div><br></div><div>Il mio piano che avevo in mente è più o meno simile. Tenendo conto delle retrocompatibilità di py.test rispetto a unitest dovrei riuscire ad introdurlo in modo abbastanza indolore e poi migrare un po' alla volta, dove mi serve, usando fixture al posto di setUp/tearDown<br></div><div>Rifattorizzare di botto tutti i setUp/tearDown dei miei progetti sarebbe invece, nel mio caso, un esagerazione<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div><div>5. etc. etc. etc.<br></div></blockquote><div>In Python 3 puoi scrivere ...</div><div>E' sintassi valida.</div></div></div></div></blockquote><div><br></div><div>uhm, questa temo di non averla capita ...<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div><div>6. ah, già, anche... dovrei dare un occhiata al progetto pypy</div></blockquote></span></div><br>Ottima idea.<span class=""><font color="#888888"><br></font></span></div></div></blockquote><div><br></div><div>già, indubbiamente, me lo dico da tempo<br></div><div>ma dato che i miei progetti sono soprattutto DB-bound (si può dire?) guadagnare sul CPU-time lato pure-python sarebbe più o meno inifluente<br></div><div>Ma vedi sopra per il ... "datemi un occasione per giocarci" :-)<br></div><div><br></div><div>-marco-</div></div><br></div></div>