Re: [Python] Python exception or return code.
Il 01 marzo 2015 01:10:51 CET, Massimiliano della Rovere massimiliano.dellarov...@gmail.com ha scritto: 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: [...] Argh... Come soffro Byez -- Gollum1 Teoro, dov'è il mio teoro Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli errori di battitura (maledetto correttore automatico). ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
2015-02-28 19:34 GMT+01:00 enrico franchi enrico.fran...@gmail.com: [...] 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). Pensa a panic come una eccezione hardware, tipo SIGSEGV. Non è una situazione da cui puoi effettuare un ricovero normale. In alcuni casi panic viene anche usato quando i parametri di un costruttore non sono validi (in questo caso, in un mondo ideale, l'errore dovrebbe essere riportato dal compilatore). [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
2015-02-28 23:00 GMT+01:00 enrico franchi enrico.fran...@gmail.com:
[...]
Perche' voglio dire... potremmo scrivere intere librerie e framework in
Python (per dire) con la convenzione di ritornare tuple per la roba che
puo' fallire. Alla fine credo che non si faccia non solo perche' non e' la
maniera di Python, ma sopratutto perche' spesso e' scomodo.
Io personalmente non trovo particolarmente carino qualcosa tipo
func doSomething() (res Result, err error) {
op, err := operation1()
if err != nil {
return
}
mah, err := operation2(op)
if err != nil {
return
}
res, err := operation3(op, mah)
return
}
rispetto a qualcosa come
def do_something():
op = operation1()
return operation3(op, operation2(op))
Sara' che mi devo ancora abituare...
Il problema è che per capire Go devi leggere alcuni articoli chiave, come:
http://blog.golang.org/errors-are-values
http://blog.golang.org/constants
La documentazione di Go, AFAIK, è ancora abbastanza frammentata.
Io infatti ci ho messo più tempo di quanto avrei dovuto per entrare nel
linguaggio.
Ciao Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
2015-03-01 0:12 GMT+00:00 Giorgio Zoppi giorgio.zo...@gmail.com: Si, Grazie interessanti punti di vista. Il viaggio del apprendista stregone informatico inizia da consegnare: 1. codice bug free 2. codice bug free in qualsiasi condizione esterna. Io direi che qui terminerebbe, ammesso che ci si arrivasse mai. Salvo che le due condizioni sono equivalenti (se non hai bachi, non hai bachi manco in condizioni estreme; se hai bachi che si manifestano solo in condizioni estreme, vuole dire che comunque hai bachi). Mi sembra un po' una vana speranza: codice *senza* bachi sopra una certa dimensione non e' che ne veda molto. In questo caso si han di fronte tre cose: 1. Programmer bugs 2. Errori recuperabili (soft error) 3. Errori non recuperabili. Bene. La domanda e' siccome mi interessa la vostra esperienza, come gestite i punti 2, 3. La classificazione che proponi non mi fa impazzire troppo (nel senso che e' molto difficile separare i punti 2 e 3 a priori... mentre e' relativamente chiaro come funziona a posteriori). Faccio un esempio: devo parlare con un servizio. Allora vado a risolvere il nome sul DNS. Non ho risposta. Cosa e'? Non ho modo di saperlo. Probabilmente voglio una strategia di retry; se qualcuno si era mangiato il mio pacchetto UDP per caso, probabilmente avro' risposta. Mi sembra un esempio di errore recuperabile. Se invece tutta l'infrastruttura del DNS ha preso fuoco e sta malamente capitolando... diciamo che probabilmente sto per fronteggiare un fallimento totale. Ma ancora... non e' chiaramente un bug (non nel mio software); e' un fallimento esterno. Diciamo che in generale quando sono in una condizione che non posso recuperare dentro l'applicativo quello che faccio e' fare in modo che le cose vengano escalate ad un umano (allarmi, ticket). Il resto quando possibile cerco di recuperarlo. Ma anche li... fare il retry di ogni chiamata ad un servizio fallita (seguendo la semantica HTTP) non e' sempre la cosa giusta. A volte e' meglio semplicemente fare fallire la chiamata di piu' alto livello e l'utente provera' a ricaricare, il motivo e' che altrimenti comunque la risposta all'utente e' troppo lenta (e c'e' caso che provera' a ricaricare comunque, con conseguenze consumo di risorse), inoltre rischia di sovraccaricare la rete e/o i servizi accessori. In altri casi il retry e' un salva vita. Poi ci sono casi in cui non ha senso. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
2015-03-01 7:37 GMT+00:00 Giovanni Porcari giovanni.porc...@softwell.it: Ti devo una birra in più ;) Gia' capito che finisco sbronzo... :) -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
2015-03-01 14:40 GMT+00:00 Manlio Perillo manlio.peri...@gmail.com: Pensa a panic come una eccezione hardware, tipo SIGSEGV. Non è una situazione da cui puoi effettuare un ricovero normale. Ma si, questo mi e' chiaro. Non e' un segreto in Go. Anche se... per esempio se accedo fuori bound ad un array mi prendo un panic. Ora... alcune volte accedere a memoria a caso e' appunto un errore hardware. Altre volte e' solo un errore dal punto di vista del linguaggio, non dell'hardware. Quello che intendo, e' che se in C ho questo char foo[4]; char bar[4]; char baz[4]; Se da bar vado fuori sono in piena undefined behavior del linguaggio. A seconda di come funziona lo stack della piattaforma potrei finire in foo o in baz. Oppure potrei finire altrove ancora, non ho nessuna garanzia. Appunto, sono in undefined behavior. Ma se faccio la stessa cosa concettualemnte in asm[0] non sto violando nulla: non e' un errore hardware. -- [0] ovvero scrivo un programma che mi mette sullo stack abbastanza per ficcarci 12 caratteri che uso come 4 array separati e da quello di mezzo mi metto su uno degli altri due, sto probabilmente ancora violando la semantica che mi sono imposto, ma per il processore non sto facendo nulla di male. O poi mi va anche bene che gli accessi out mi diano panic... sarebbe veramente complicato avere una signature tipo el, err = arr[1] In alcuni casi panic viene anche usato quando i parametri di un costruttore non sono validi (in questo caso, in un mondo ideale, l'errore dovrebbe essere riportato dal compilatore). Che poi e' uno dei motivi per cui a suo tempo le eccezioni si diffusero... -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
2015-03-01 16:33 GMT+01:00 enrico franchi enrico.fran...@gmail.com: 2015-03-01 14:40 GMT+00:00 Manlio Perillo manlio.peri...@gmail.com: In alcuni casi panic viene anche usato quando i parametri di un costruttore non sono validi (in questo caso, in un mondo ideale, l'errore dovrebbe essere riportato dal compilatore). Che poi e' uno dei motivi per cui a suo tempo le eccezioni si diffusero... Abbiamo la cattiva abitudine di abusare di qualsiasi nuovo strumento che ci offre maggiore potenza rispetto agli strumenti precedenti. Probabilmente perchè gli strumenti precedenti erano troppo rudimentali. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
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
Re: [Python] Python exception or return code.
2015-02-28 23:32 GMT+00:00 Giovanni Porcari giovanni.porc...@softwell.it: 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 ? Un dettaglio che ti impedirebbe di farlo e' che determinati oggetti in Python *non* hanno attributi arbitrari. Per esempio None. Non riusciresti ad attaccargli sopra x.__error__. Questo e' un motivo duro per cui non si puo' fare. Ma ovviamente se si fosse voluto fare si sarebbe potuto dotare qualunque oggetto di un attributo __error__. Sulla parte pratica, credo che alla fine dei conti scrivere x = f() if x.__error__: ... non porti vantaggio rispetto ad altri modi di gestire l'errore. Confronta con res, error = f() if error: ... e vedi che non e' che sia una miglioria enorme. Inoltre ci sono cose minori, tipo il fatto di dovere pagare sempre un puntatore (o analogo) per ogni oggetto (quindi un consumo di memoria non trascurabile), anche quelli che non ne avrebbero bisogno. Semmai la parte interessante potrebbe in qualche modo essere il concetto di auto-propagare l'errore. Ovvero l'idea e' che se hai un __error__ in entrata fai uscire qualcosa con un __error__. Questa strategia avrebbe comunque due problemi abbastanza massicci: 1. e' terribilmente implicita. temo si finirebbe con un problema che alla fine ha un __error__ e non si sa perche' (a meno di non avere una strategia molto complicata e molto costosa per accumulare gli errori 2. in generale se hai un errore non sei in grado di darmi un oggetto che abbia una parvenza di significato e appiccicargli __error__ non migliora troppo le cose. Mi spiego... se mi fai un metodo che ritorna una lista, mi ritorni una lista vuota con __error__ e la cosa funziona (mi distingue il caso in cui la lista vuota e' il vero ritorno e mi costruisci un valore valido del tipo che vuoi ritornare). Ma ci sono tipi che non hanno una lista vuota. Che so... un libro. Che facciamo il libro vuoto? Cioe', in teoria si potrebbe creare un linguaggio che funziona cosi'... alla fine dei conti si chiama NullObjectPattern (meno il __error__) e in determinate circostanze e' buono. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
2015-02-28 21:04 GMT+00:00 Nicola Larosa n...@teknico.net:
Enrico Franchi wrote:
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)
No no, che diffuso, il modo è quello e basta, vedi blog ufficiale:
Error handling and Go
http://blog.golang.org/error-handling-and-go
Defer, Panic, and Recover
http://blog.golang.org/defer-panic-and-recover
nonché l'autorevole Dave Cheney:
Why Go gets exceptions right
http://dave.cheney.net/2012/01/18/why-go-gets-exceptions-right
Il modo e' quello perche' la stragrande maggioranza del codice Go fa
quello.
Personalmente, trovo sensato nella gran parte dei casi. Trovo che in altri
casi sia piu' sensato gestire gli errori tramite callback, o per lo meno,
progettare l'API in quella maniera. Poi chiaro come il sole che diventa
tutto piu' complesso.
Detto poi fra noi, fra la gestione degli errori di Python non so quale mi
piace di piu'. Devo cominciare ad avere roba in Go che fallisce male per
entrare davvero in mentalita'. Ovvero... in C la mancanza delle eccezioni
la sento tantissimo. In Haskell (che pure le ha, sebbene in generale non
sia idiomatico usarle come si farebbe in Python) ci sono stati casi in cui
le avrei volute. In Go per ora no... ma non e' che mi sia chiaro perche'
non mi manchi. Credo che sia perche' ho scritto davvero troppo poco codice
e non mi sono ancora rotto le palle di fare a mano cose che con le
eccezioni avrei gratis.
Perche' voglio dire... potremmo scrivere intere librerie e framework in
Python (per dire) con la convenzione di ritornare tuple per la roba che
puo' fallire. Alla fine credo che non si faccia non solo perche' non e' la
maniera di Python, ma sopratutto perche' spesso e' scomodo.
Io personalmente non trovo particolarmente carino qualcosa tipo
func doSomething() (res Result, err error) {
op, err := operation1()
if err != nil {
return
}
mah, err := operation2(op)
if err != nil {
return
}
res, err := operation3(op, mah)
return
}
rispetto a qualcosa come
def do_something():
op = operation1()
return operation3(op, operation2(op))
Sara' che mi devo ancora abituare...
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).
panic non è inteso per essere usato come eccezione, e la sintassi
scomoda è intenzionale. Non farlo, faresti piangere Rob Pike prima che
Gesù bambino, e tu non vuoi questo, vero?
Mi e' chiaro. La funzionalita' e' praticamente equivalente e hanno reso
molto chiaro che gli hanno dato una sintassi brutta e scomoda per non
incoraggiare. Poi detto fra noi, visto che Go schietto va di CSP e non di
Actor model [0] non sarebbe particolarmente facile gestire le eccezioni che
dovessero uscire dalle goroutine -- a meno di non ricostruirci sopra
l'actor model --.
O meglio... non sono completamente d'accordo con paninc non e' inteso per
essere usato come eccezione. Nel senso che panic/defer/recover ti
permetterebbero di costruire il classico error handling ad eccezioni.
Quello su cui sono d'accordo e' che Go idiomatico non usa le eccezioni
quando in altri linguaggi si userebbero, tutto li.
Alla fine nei vari linguaggi cambia tantissimo la pragmatica sull'uso delle
eccezioni. Python e' sul lato dello spettro le eccezioni per il normale
controllo di flusso sono perfettamente normali e non sono particolarmente
eccezionali, go e' sul lato opposto.
---
[0] non e' che parlo di impossibilita' effettiva, semplicemente il modello
e' sufficientemente diverso da non rendere comoda sta faccenda, tipo
linkare gli actors e avere il watcher che si suca le eccezioni del watched
e ci fa cose... si puo' creare tutto con le goroutine, niente da dire, ma
Go non e' concepito a quel modo e mi sta bene.
--
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
Enrico Franchi wrote: 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) No no, che diffuso, il modo è quello e basta, vedi blog ufficiale: Error handling and Go http://blog.golang.org/error-handling-and-go Defer, Panic, and Recover http://blog.golang.org/defer-panic-and-recover nonché l'autorevole Dave Cheney: Why Go gets exceptions right http://dave.cheney.net/2012/01/18/why-go-gets-exceptions-right 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). panic non è inteso per essere usato come eccezione, e la sintassi scomoda è intenzionale. Non farlo, faresti piangere Rob Pike prima che Gesù bambino, e tu non vuoi questo, vero? -- Nicola 'tekNico' Larosa http://www.tekNico.net/ Having a female-typical corpus callosum isn't a bug, it's a feature. - Eric Raymond, August 2013 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
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
Re: [Python] Python exception or return code.
Si, Grazie interessanti punti di vista. Il viaggio del apprendista stregone informatico inizia da consegnare: 1. codice bug free 2. codice bug free in qualsiasi condizione esterna. In questo caso si han di fronte tre cose: 1. Programmer bugs 2. Errori recuperabili (soft error) 3. Errori non recuperabili. Bene. La domanda e' siccome mi interessa la vostra esperienza, come gestite i punti 2, 3. Saluti, Giorgio. Il giorno 1 marzo 2015 00:32, 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 -- Quiero ser el rayo de sol que cada día te despierta para hacerte respirar y vivir en me. Favola -Moda. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
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'. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python exception or return code.
Il giorno 01/mar/2015, alle ore 01:35, enrico franchi enrico.fran...@gmail.com ha scritto: 2015-02-28 23:32 GMT+00:00 Giovanni Porcari giovanni.porc...@softwell.it: 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 ? Un dettaglio che ti impedirebbe di farlo e' che determinati oggetti in Python *non* hanno attributi arbitrari. Per esempio None. Non riusciresti ad attaccargli sopra x.__error__. Questo e' un motivo duro per cui non si puo' fare. Ma ovviamente se si fosse voluto fare si sarebbe potuto dotare qualunque oggetto di un attributo __error__. Si esatto. Intendevo un attributo di sistema e non di attributo appiccicato ad minchiam da me. Sulla parte pratica, credo che alla fine dei conti scrivere x = f() if x.__error__: ... non porti vantaggio rispetto ad altri modi di gestire l'errore. Confronta con res, error = f() if error: ... e vedi che non e' che sia una miglioria enorme. No certo. Mai pensato che lo fosse :D. Inoltre ci sono cose minori, tipo il fatto di dovere pagare sempre un puntatore (o analogo) per ogni oggetto (quindi un consumo di memoria non trascurabile), anche quelli che non ne avrebbero bisogno. Semmai la parte interessante potrebbe in qualche modo essere il concetto di auto-propagare l'errore. Ovvero l'idea e' che se hai un __error__ in entrata fai uscire qualcosa con un __error__. Questa strategia avrebbe comunque due problemi abbastanza massicci: 1. e' terribilmente implicita. temo si finirebbe con un problema che alla fine ha un __error__ e non si sa perche' (a meno di non avere una strategia molto complicata e molto costosa per accumulare gli errori 2. in generale se hai un errore non sei in grado di darmi un oggetto che abbia una parvenza di significato e appiccicargli __error__ non migliora troppo le cose. Mi spiego... se mi fai un metodo che ritorna una lista, mi ritorni una lista vuota con __error__ e la cosa funziona (mi distingue il caso in cui la lista vuota e' il vero ritorno e mi costruisci un valore valido del tipo che vuoi ritornare). Ma ci sono tipi che non hanno una lista vuota. Che so... un libro. Che facciamo il libro vuoto? Cioe', in teoria si potrebbe creare un linguaggio che funziona cosi'... alla fine dei conti si chiama NullObjectPattern (meno il __error__) e in determinate circostanze e' buono. Grazie Enrico mi hai dato ottimi spunti di riflessione. Ti devo una birra in più ;) G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
