> 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

Rispondere a