[Python] Python exception or return code.

[Massimiliano della Rovere]

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.dellarovere a 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.porcari a softwell.it> ha scritto:
>
>
>> > Il giorno 28/feb/2015, alle ore 19:34, enrico franchi <
>> enrico.franchi a gmail.com> ha scritto:
>> >
>> >
>> >
>> > On Sat, Feb 28, 2015 at 2:06 PM, Giorgio Zoppi <giorgio.zoppi a 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 a lists.python.it
>> http://lists.python.it/mailman/listinfo/python
>>
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150301/29d428b0/attachment.html>