<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-03-03 22:18 GMT+00:00 Enrico Bianchi <span dir="ltr"><<a href="mailto:enrico.bianchi@ymail.com" target="_blank">enrico.bianchi@ymail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
</blockquote></span>
Non lo e`, perche` se scelgo Python (ma anche Perl, Ruby o Lua) per fare scripting, lo faccio proprio per la flessibilita` che mi da sia il linguaggio che il suo sistema di librerie. In altre parole, subprocess lo uso solo quando mi e` strettamente necessario, e non come unica risorsa disponibile.</blockquote><div><br></div><div>Se vuoi usare Python per fare automazione di cose, ti troverai spesso ad usare subprocess. Mica per altro... semplicemente molti task specifici non hanno un equivalente di libreria (e scriverlo costa troppo), oppure l'interfaccia dell'eseguibile e' piu' comoda per quel task della libreria (evito di fare esempi perche' se no finisce che ci concentriamo sugli esempi).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Per tutto il resto, metto in gioco le librerie che mi servono, altrimenti tanto vale rimanere a bash vivere felice in quel mondo (che, nonostante quello che si dice, puo` avere senso)</blockquote><div><br></div><div>Allora, proviamo a fare un riassunto?</div><div>1: Esiste questa condizione X che e' sgradevole. Per esempio quando fai Y, X si manifesta.</div><div>2: A si, ma invece di fare Y dovresti fare Z.</div><div><br></div><div>Resta il fatto che X esiste. </div><div><br></div><div>In altre parole, tu stai rispondendo al fatto che ci sia un baco in subprocess dicendo che non e' rilevante perche' uno specifico eseguibile che triggera il baco puo' essere sostituito dalla standard library. Quello che sto dicendo e' che il semplice fatto che tar -z possa essere rimpiazzato dalla standard library non vuole dire che il baco non sia un problema. Non ho davvero voglia di mettermi a fare una lista di software comunemente distribuiti che in qualche momento della loro esistenza tirano su una pipe fra un processo padre e un processo figlio. Perche' questa e' la condizione che scatena il baco. Non e' tar in se che e' malvagio.</div><div><br></div><div>Non ho intenzione di commentare poi su tarlib e combriccola, perche' poi e' chiaro che finiremmo a parlare di tarlib.</div><div><br></div><div>Tra l'altro, sei d'accordo con me che si, bash puo' avere senso. Giuro che non capisco quale sia il punto.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ovvero, usare qualcosa che fa delle pipe e' buggato; per esempio il comune tar -z crea delle pipe. Devo chiarificare ulteriormente?<br>
</blockquote></span>
Sei stato chiarissimo, cosi` come e` chiaro che quel bug e` chiuso.</blockquote><div><br></div><div>Come gia' ti dissi, quel baco e' chiuso nel bugtracker, ma non e' risolto in Python 2.7. Chiudere qualcosa nel bugtracker non vuole dire averlo fixato, sfortunatamente. Non credo che tu possa sostenere che i deployment di Python 2.7 sono una piccola parte dei deployment di Python. A me verrebbe anzi da dire che tutt'ora la maggior parte dei Python in produzione sono 2. Quindi per quanto chiuso, quel baco e' tutt'ora rilevantissimo.</div><div><br></div><div><br></div></div>-- <br><div> .<br>..: -enrico-</div>
</div></div>