Mi è venuto in mente che alla lista va aggiunto anche l'AsyncResult di gevent http://www.gevent.org/gevent.event.html#gevent.event.AsyncResult i cui attributi "value" e "exception" implementano la logica che vorresti.
Il giorno dom 1 mar 2015 00:57 Massimiliano della Rovere < massimiliano.dellarov...@gmail.com> ha scritto: > Si pone però un problema in questo scenario: > dato che il risultato non può essere generato (a causa dell'errore), manca > qualcosa a cui agganciare il magic method __error__. > > Una possibile soluzione a questo problema sono: > - i deferred di Twisted > https://twistedmatrix.com/documents/current/core/howto/defer.html > > - i futures di Python 3.3+ > https://docs.python.org/3/library/concurrent.futures.html#future-objects > > - i future di tornado: > http://www.tornadoweb.org/en/stable/concurrent.html > > > (e in Javascript la libreria Q: > http://www.html.it/articoli/javascript-asincrono-le-promise-e-la-libreria-q/ > ) > > Il giorno dom 1 mar 2015 alle ore 00:33 Giovanni Porcari < > giovanni.porc...@softwell.it> ha scritto: > > >> > Il giorno 28/feb/2015, alle ore 19:34, enrico franchi < >> enrico.fran...@gmail.com> ha scritto: >> > >> > >> > >> > On Sat, Feb 28, 2015 at 2:06 PM, Giorgio Zoppi <giorgio.zo...@gmail.com> >> wrote: >> > Vorrei aprire una discussione senza cadere nella trappola del >> > expert beginner. >> > In Python in quali casi e' preferibile usare eccezzioni o in quali casi >> e' preferibile usare return codes. Secondo la teoria, spiegata in Framework >> Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET >> Libraries, : >> > "Exceptions integrate well with object-oriented languages. >> Object-oriented languages tend to impose constraints on member signatures >> that are not imposed by functions in non-OO languages. For example, in the >> case of constructors, operator overloads, and properties, the developer has >> no choice in the return value. For this reason, it is not possible to >> standardize on return-value-based error reporting for object-oriented >> frameworks. An error reporting method, such as exceptions, which is out of >> band of the method signature is the only option." >> > >> > Ma ne la vita quotidiana si apprende dell'esperienza e non solo dalla >> teoria. Durante la vostra esperienza vi e' capitato di decidere questo? >> > >> > Non capisco la domanda. Stai chiedendo se ho mai usato le eccezioni >> (si), se ho mai scritto codice che lancia intenzionalmente eccezioni (si), >> se ho mai scritto codice che non avrei potuto scrivere facilmente senza >> eccezioni (essenzialmente si) o quale sia la mia posizione a riguardo? >> > >> > Come dire... boh. Dipende dal linguaggio e dipende dal contesto. Tipo >> in Java lavorare con le eccezioni pone limitazioni simili a lavorare >> "liberalmente" con i tipi di ritorno. Poi i tipi di ritorno hanno sempre il >> problema del valore nullo (controllare tutto per None e' in generale >> seccante, specie quando questo ti costringe a rendere None "invalido" >> perche' deve mostrarti l'errore -- in questo preferisco di gran lunga >> Maybe/Optional, che almeno funziona come si deve). >> > >> > In Python la tradizione e' fare un uso abbastanza liberale delle >> eccezioni. Di per se si potrebbe avere anche la convenzione di ritornare >> *sempre* una tupla con qualcosa che indica l'errore. In Go si fa cosi' (o >> per lo meno, e' diffuso) ed e' piuttosto accettabile. Ci sono momenti in >> cui vorrei avere eccezioni vere e proprie, ma la cosa finisce li (si, so di >> panic, ma la sintassi e' talmente orribile che mi sembra di fare piangere >> gesubambino per niente). >> > >> > In Haskell anche li le eccezioni ci sono, ma fino ad un certo punto. >> Trovo che non si integrino eccellentemente nel resto del linguaggio, per >> cui in generale tendo ad usare Maybe/Either. Alcune volte mi sono mancate. >> Ma sono secoli che non lavoro con Haskell. >> > >> > Personalmente trovo che in un contesto imperativo/OOP le eccezioni >> siano proprio una gran cosa. Le proprieta' che hanno sul controllo di >> flusso sono spesso complicate da implementare altrimenti (o meglio, non >> complicate, solo un sacco di boilerplate). Poi ci sono i problemi >> accessori: seguire il controllo di flusso puo' diventare davvero un incubo, >> visto che diventa non predicibile manco sapere se qualcosa termina >> guardandolo. >> > >> > def will_it_ever_end(a, b): >> > while 1: >> > a += b >> > >> > Davvero non abbiamo modo di sapere cosa succedera'. >> > >> > >> > >> > >> >> Ho già avuto modo di dire che sono solo un autodidatta sia pure di lunga >> data >> e quindi so che in questo momento rischio di dire fregnacce. >> >> Però mi sono sempre chiesto una cosa: siccome in python comunque tutto è >> un oggetto, >> non sarebbe in qualche modo plausibile rendere l'errore come attributo >> del risultato ? >> Se ad esempio scrivo x=f(y) allora posso poi testare x.__error__ per >> sapere se c'è stato un errore. >> >> Sono ragionevolmente certo che ci sia qualcosa di sbagliato in questo >> ragionamento ma >> sono troppo ignorante sulla parte teorica di python (o meglio in generale >> sui linguaggi) >> per capirlo. Enrico mi aiuti ? >> >> Ciao >> >> G. >> >> >> >> >> >> _______________________________________________ >> Python mailing list >> Python@lists.python.it >> http://lists.python.it/mailman/listinfo/python >> >
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python