Discussion:
whyname corregido
Juan B Cabral
2008-10-03 19:34:18 UTC
Permalink
Corregi mi proyecto dadas las sugerencias de los Igores[0] voluntarios

cuando el codigo tenga 0 criticas me dedicare a la documentacion y
distribucin (recordemos que aun estoy aprendiendo y le pongo pilas para
dejar el mejor producto posible)

ahora respondo algunas preguntas:

1 - el tema de por que meto tanto la pata con los except son costumbres
java (ya se van a ir) de todas maneras dejo unos raise para algunos
tipos de exceptions que no se que no debo hacer nada.

2 - mi costumbre de toReturn, toWrite... viene principalmente de una
confusion que tube con un profe de la facu. el tipo en su perra vida
identificaba la variable donde resolvia la funcion. Con eso dejo muy en
claro y nunca mas se confundio. A mi particularmente me resulta muy muy
comodo que si tengo un metodo "get_wawawa()" si adentro hay una var del
tipo "toReturn" es esa la variable donde se carga todo lo que se "debe"
cargar... es cuestion de gustos... a lo sumo la adaptare mas a lo python
como "to_return". pero simplementem me gusta

gracuas a los igores y se agradecen que "sigan bajando" la palanca para
ver si la critura vive.(osea sigan criticando)

ya implementare el optparse esta noche o mañana

JuanBC

[0] http://en.wikipedia.org/wiki/Igor_(fictional_character)
Juan B Cabral
2008-10-03 19:41:24 UTC
Permalink
y como buen inteligente que soy aca recien va el link

http://code.google.com/p/whyname/
Gabriel Genellina
2008-10-03 21:29:51 UTC
Permalink
En Fri, 03 Oct 2008 16:34:18 -0300, Juan B Cabral
Post by Juan B Cabral
Corregi mi proyecto dadas las sugerencias de los Igores[0] voluntarios
cuando el codigo tenga 0 criticas me dedicare a la documentacion y
distribucin (recordemos que aun estoy aprendiendo y le pongo pilas para
dejar el mejor producto posible)
1 - el tema de por que meto tanto la pata con los except son costumbres
java (ya se van a ir) de todas maneras dejo unos raise para algunos
tipos de exceptions que no se que no debo hacer nada.
Java tiene excepciones chequeadas (una metida de pata de diseño) y
entonces es re comun que haya que atrapar todas las excepciones que
aparecen nada mas para cambiarles el tipo. Eso para lo unico que sirve es
para esconder informacion valiosa (como cuál fue el verdadero error
original), o induce a que los programadores escriban [el equivalente a]
esto:
try: ...
except: pass
que es como esconder el polvo abajo de la alfombra.

En Python la regla sería, parafraseando a mi abuela: "Si no tenes nada
bueno que hacer con la excepcion, sencillamente no la atrapes". Que siga
su curso, hasta que alguien más arriba con mas "contexto" la atrape y haga
algo útil.

En este ejemplo:

def get_whyname():
toReturn = _get_hostname() + ":\n\t"
try:
toReturn += _read_file()
except IOError, e:
if e.errno == 2 or e.errno == 21:
toReturn += 'A name policy has not been defined.'
else:
raise e
except:
raise
return toReturn

El except: raise esta de mas, lo podes sacar y no pasa nada. O sea: una
clausula except que *solo* contiene un raise, es totalmente transparente,
como si no existiera; solo sirve para alargar el codigo en numero de
lineas y en tiempo de ejecucion.
El `raise e` de mas arriba, sí deberia ser un raise pelado. Tal como está
ahora, el error "nace" en la linea que dice `raise e`, y eso es lo que te
mostraria un traceback. Pero en realidad es anterior, el error saltó al
intentar abrir el archivo, y sería bueno que te lo muestre así. Para eso
usas `raise`, a secas, que lanza la ultima excepcion manteniendo el
traceback completo original.

Otra cosa es que esta mezclado en el script principal, si start()
*imprime* un texto o *devuelve* un texto (en caso de error, imprime y
devuelve). En general, diria que start() y _get_response tienen
responsabilidades mezcladas (podrías decir *que* hace cada una en una sola
oracion?).

Y en general, yo prefiero que los errores se propaguen a traves de
excepciones, y no a traves del valor retornado por la funcion. O sea, si
set_whyname_string no puede hacer lo que se supone que tiene que hacer,
entonces lanza una excepcion; vos en su lugar estas devolviendo el texto
"You not have permisions to read: \n\t" + path
Por ejemplo,si el que invoco set_whyname_string quiere saber si anduvo
bien o no, es dificil, hay que andar mirando el texto devuelto a ver si
tiene pinta de error. Y si no lo verificas en el mismo lugar en que
hiciste la llamada, perdiste - se pierde esa informacion. Eso es lo bueno
de usar excepciones (el tratamiento del problema se difiere hasta el
momento en que alguien esta en condiciones de hacer algo util, no hace
falta hacerlo en el mismisimo lugar en que se detectó).
Post by Juan B Cabral
2 - mi costumbre de toReturn, toWrite... viene principalmente de una
confusion que tube con un profe de la facu. el tipo en su perra vida
identificaba la variable donde resolvia la funcion. Con eso dejo muy en
claro y nunca mas se confundio. A mi particularmente me resulta muy muy
comodo que si tengo un metodo "get_wawawa()" si adentro hay una var del
tipo "toReturn" es esa la variable donde se carga todo lo que se "debe"
cargar... es cuestion de gustos... a lo sumo la adaptare mas a lo python
como "to_return". pero simplementem me gusta
Ok, yo dentro de get_wawawa() usaria una variable llamada wawawa para ir
guardando lo que voy a devolver... pero si, es cuestion de gustos nomas. A
veces uso result, porque la mitad del tiempo programo en Delphi.
Post by Juan B Cabral
gracuas a los igores y se agradecen que "sigan bajando" la palanca para
ver si la critura vive.(osea sigan criticando)
Estoy criticón, se nota? Pero va con onda... :)
--
Gabriel Genellina
Mariano Guerra
2008-10-03 22:17:56 UTC
Permalink
Java tiene excepciones chequeadas (una metida de pata de diseño) y entonces
es re comun que haya que atrapar todas las excepciones que aparecen nada mas
para cambiarles el tipo. Eso para lo unico que sirve es para esconder
informacion valiosa (como cuál fue el verdadero error original), o induce a
try: ...
except: pass
que es como esconder el polvo abajo de la alfombra.
En Python la regla sería, parafraseando a mi abuela: "Si no tenes nada bueno
que hacer con la excepcion, sencillamente no la atrapes". Que siga su curso,
hasta que alguien más arriba con mas "contexto" la atrape y haga algo útil.
quería agregar algo a la discusión, si bien es insoportable que el
lenguaje te obligue a tratar excepciones en todos lados o a reportar
explícitamente que no la vas a tratar, esta bueno que el lenguaje sea
capaz de averiguar y decirte cuales excepciones tira un método.
Por ejemplo, en C# no te reta si no tratas una excepción y no tenes
que declarar que la tiras, pero tampoco te dice cuales son las que
tira, lo que lleva a buscar las excepciones que tira en la
documentacion y el 99% del tiempo nadie escribe que excepciones puede
tirar por la simple razón de que documentar es un perno y que de
arranque no sabes que excepciones tiran los métodos que usas vos.
A que voy con esto? me encantaría que python siga como es, pero que
si me interesa, me diga que excepciones pueden llegar a saltar, de esa
manera si realmente quiero hacer un try/except, puedo tratar las
excepciones de una forma "granular" y no hacer un except Exception
porque no se que puede saltar o ir agregando clausulas a medida que
saltan. :)

solo son deseos.. :D
Gabriel Genellina
2008-10-03 23:53:24 UTC
Permalink
En Fri, 03 Oct 2008 19:17:56 -0300, Mariano Guerra
2008/10/3 Gabriel Genellina
Post by Gabriel Genellina
En Fri, 03 Oct 2008 16:34:18 -0300, Juan B Cabral
En Python la regla sería, parafraseando a mi abuela: "Si no tenes nada bueno
que hacer con la excepcion, sencillamente no la atrapes". Que siga su curso,
hasta que alguien más arriba con mas "contexto" la atrape y haga algo útil.
quería agregar algo a la discusión, si bien es insoportable que el
lenguaje te obligue a tratar excepciones en todos lados o a reportar
explícitamente que no la vas a tratar, esta bueno que el lenguaje sea
capaz de averiguar y decirte cuales excepciones tira un método.
Por ejemplo, en C# no te reta si no tratas una excepción y no tenes
que declarar que la tiras, pero tampoco te dice cuales son las que
tira, lo que lleva a buscar las excepciones que tira en la
documentacion y el 99% del tiempo nadie escribe que excepciones puede
tirar por la simple razón de que documentar es un perno y que de
arranque no sabes que excepciones tiran los métodos que usas vos.
A que voy con esto? me encantaría que python siga como es, pero que
si me interesa, me diga que excepciones pueden llegar a saltar, de esa
manera si realmente quiero hacer un try/except, puedo tratar las
excepciones de una forma "granular" y no hacer un except Exception
porque no se que puede saltar o ir agregando clausulas a medida que
saltan. :)
Creo que estas enfocando el problema al reves. En general, no hace falta
que atrapes las excepciones que no conoces. Si vas a atrapar una excepcion
es porque queres hacer algo especifico con ella - si no tenes nada bueno
para hacer, no la atrapes y punto.
Si pensas que sí hace falta atraparla, es porque posiblemente estas
pensando en un modelo de ejecución donde los errores se propagan a traves
de un codigo de retorno (típicamente: 0=OK, 1=paso tal cosa, 2=paso tal
otra...). En un modelo basado en excepciones, esto no es asi: si sucede
algun problema, lo comunicas a traves de una excepcion, no de un codigo de
retorno. Y dejas que la excepcion siga su curso hasta que "alguien" la
atrape porque tiene algo "util" que hacer con ella.
Por ejemplo, tu funcion set_whyname_file ahora devuelve un *texto* de
error. Vos sentis la "necesidad" de atrapar todas las excepciones
posibles, para poder devolver un texto válido en cada caso. Si esa funcion
simplemente lanzara una excepcion cuando hay un problema (bien sea el
IOError original, o cualquier otra cosa), entonces no tendrias la
"necesidad" de atrapar nada.
En un lenguaje con buen soporte de excepciones como es Python (o C++ para
mencionar algun otro), ésa es la mejor forma. En otros lenguajes (como C
por ejemplo) no te queda otra que pasarte la vida chequeando codigos de
retorno una y otra vez, en todas y cada una de las funciones que llamas.
Te olvidaste de hacerlo en algun lado (porque se te paso, por ignorancia,
porque estabas cansado, porque pensaste "esto no puede fallar nunca"...) y
ya tu programa hace cualquier verdura y es dificil darse cuenta qué pasó...

Claro que hay situaciones donde realmente convendría saber cuáles
excepciones podrían suceder, pero en general es algo imposible de
determinar a priori. Cualquier funcion puede disparar cualquier excepcion,
y no hay forma de predecirlo. open(filename) *usualmente* falla con
IOError, pero si filename no es una string va a saltar un TypeError, y
siempre podria haber un MemoryError, y si el nombre "open" apunta a otro
objeto que no es la funcion predefinida "open" (como en la version
anterior de tu programa, que redefinia string y list como variables), el
resultado puede ser absolutamente cualquier cosa. Python es dinámico
también en este aspecto, asi que anda acostumbrándote...
solo son deseos.. :D
Estoy seguro de que con el tiempo se te van a pasar :)
--
Gabriel Genellina
Mariano Guerra
2008-10-04 02:01:35 UTC
Permalink
Post by Gabriel Genellina
En Fri, 03 Oct 2008 19:17:56 -0300, Mariano Guerra
Post by Mariano Guerra
Post by Gabriel Genellina
En Fri, 03 Oct 2008 16:34:18 -0300, Juan B Cabral
En Python la regla sería, parafraseando a mi abuela: "Si no tenes nada bueno
que hacer con la excepcion, sencillamente no la atrapes". Que siga su curso,
hasta que alguien más arriba con mas "contexto" la atrape y haga algo útil.
quería agregar algo a la discusión, si bien es insoportable que el
lenguaje te obligue a tratar excepciones en todos lados o a reportar
explícitamente que no la vas a tratar, esta bueno que el lenguaje sea
capaz de averiguar y decirte cuales excepciones tira un método.
Por ejemplo, en C# no te reta si no tratas una excepción y no tenes
que declarar que la tiras, pero tampoco te dice cuales son las que
tira, lo que lleva a buscar las excepciones que tira en la
documentacion y el 99% del tiempo nadie escribe que excepciones puede
tirar por la simple razón de que documentar es un perno y que de
arranque no sabes que excepciones tiran los métodos que usas vos.
A que voy con esto? me encantaría que python siga como es, pero que
si me interesa, me diga que excepciones pueden llegar a saltar, de esa
manera si realmente quiero hacer un try/except, puedo tratar las
excepciones de una forma "granular" y no hacer un except Exception
porque no se que puede saltar o ir agregando clausulas a medida que
saltan. :)
el que escribio el texto al que estas respondiendo soy yo, no el
creador del thread ni del programa. :D
Post by Gabriel Genellina
Creo que estas enfocando el problema al reves. En general, no hace falta que
atrapes las excepciones que no conoces. Si vas a atrapar una excepcion es
porque queres hacer algo especifico con ella - si no tenes nada bueno para
hacer, no la atrapes y punto.
Es que yo si las quiero atrapar y no se cuales son :D, para dejar mas
claro esto, te posteo un fragmento de un post que escribi en mi blog
hace mucho (estaba un poco enojado cuando lo escribi pero se rescata
el mensaje :P)

[Quote]si tenes una retorcida adicción a lanzar excepciones haceme el
favor de atraparlas, y si la vas a atrapar hace algo útil, no vale
atraparla y no hacer nada[/Qoute]

a lo que referia con retorcida adiccion es que alguien me metio un
raise cada 5 lineas de codigo en un modulo cada vez que algo no le
gustaba (digamos que en vez de hacer un if para ver si habia una
llave, tiraba una excepcion :P)
Post by Gabriel Genellina
Si pensas que sí hace falta atraparla, es porque posiblemente estas pensando
en un modelo de ejecución donde los errores se propagan a traves de un
codigo de retorno (típicamente: 0=OK, 1=paso tal cosa, 2=paso tal otra...).
Exactamente, soy partidario de lanzar excepciones en casos en los que
no puedo hacer nada para solucionar un problema (no tengo la
informacion necesaria, no es el lugar o requiero que alguien en el
stack de llamadas se entere), pero tambien soy partidario de atrapar
excepciones en el punto que corresponde haciendo lo necesario para
solucionar el problema, para evitar que la excepcion para arriba y me
termine haciendo funcionar mal el programa.
Post by Gabriel Genellina
En un modelo basado en excepciones, esto no es asi: si sucede algun
problema, lo comunicas a traves de una excepcion, no de un codigo de
retorno. Y dejas que la excepcion siga su curso hasta que "alguien" la
atrape porque tiene algo "util" que hacer con ella.
totalmente de acuerdo, el valor de retorno de una funcion lo veo como
el resultado de una funcion matematica, es el resultado de la
ejecucion de la funcion, no un medio para comunicar otras cosas..
Post by Gabriel Genellina
Por ejemplo, tu funcion set_whyname_file ahora devuelve un *texto* de error.
no es mia :D
Post by Gabriel Genellina
Vos sentis la "necesidad" de atrapar todas las excepciones posibles, para
poder devolver un texto válido en cada caso. Si esa funcion simplemente
lanzara una excepcion cuando hay un problema (bien sea el IOError original,
o cualquier otra cosa), entonces no tendrias la "necesidad" de atrapar nada.
no es mio :D, y para aclarar, no siento la necesidad de atrapar todas
las excepciones, solo tengo la necesidad de saber cuales son las
posibles excepciones que pueden saltar asi decido cuales tratar, me ha
pasado que despues de que un programa mio esta siendo usado por 6
meses me llega un bug report de una excepcion que salta en una parte y
agrego el try/except en el lugar adecuado, y a los 2 meses me llega
otro bug report con otra excepcion muy rara que salta en el mismo
lugar. Me gustaria saber cuando agrego los except cuales son las
excepciones que pueden saltar en ese lugar para tratar las que
considere "tratables" en ese punto. Ese era el punto de mi mail
anterior.
Post by Gabriel Genellina
En un lenguaje con buen soporte de excepciones como es Python (o C++ para
mencionar algun otro), ésa es la mejor forma. En otros lenguajes (como C por
ejemplo) no te queda otra que pasarte la vida chequeando codigos de retorno
una y otra vez, en todas y cada una de las funciones que llamas. Te
olvidaste de hacerlo en algun lado (porque se te paso, por ignorancia,
porque estabas cansado, porque pensaste "esto no puede fallar nunca"...) y
ya tu programa hace cualquier verdura y es dificil darse cuenta qué pasó...
totalmente de acuerdo (alguien chequea la salida de printf en C para
saber si se escribieron todos los caracteres? :D)
Post by Gabriel Genellina
Claro que hay situaciones donde realmente convendría saber cuáles
excepciones podrían suceder, pero en general es algo imposible de determinar
a priori.
Por esto me voy a tener que aguantar el odio de muchos, pero java lo
hace (o casi lo hace), no digo que sea perfecto, pero un metodo es un
arbol de llamadas a otros metodos, la forma mas simple seria recorrer
los metodos llamados y ver los raise (no es 100% efectivo, pero al
menos me da un hint de que puedo llegar a esperarme).
Post by Gabriel Genellina
Cualquier funcion puede disparar cualquier excepcion, y no hay
forma de predecirlo. open(filename) *usualmente* falla con IOError, pero si
filename no es una string va a saltar un TypeError, y siempre podria haber
un MemoryError, y si el nombre "open" apunta a otro objeto que no es la
funcion predefinida "open" (como en la version anterior de tu programa, que
redefinia string y list como variables), el resultado puede ser
absolutamente cualquier cosa. Python es dinámico también en este aspecto,
asi que anda acostumbrándote...
Estoy de acuerdo, a fin de clarificar digamos que hay tres tipos de
errores, los errores de operaciones (del tipo "no podes abrir ese
archivo" o "el archivo no existe"), las excepciones inherentes a un
lenguaje dinamico (del tipo "