2010/2/9 lasizoillo <lasizoi...@gmail.com>:
> El día 9 de febrero de 2010 15:52, Olemis Lang (Simelix)
> <olemis...@gmail.com> escribió:
>>
>>>> - Otro ejemplo, la solución al `case` o `switch` de Python basada en
>>>> dict(s)
>>>> implica q a cada llave se le asigne algo q, al ejecutarlo, se realiza
>>>> lo
>>>> q sea específico de esa alternativa. Pasa algo más o menos semejante,
>>>> en Python resulta engorroso escribir una función para cada
>>>> alternativa,
>>>> sin el propósito de reutilizarla (sino solo para suplir una carencia
>>>> del
>>>> lenguaje) y la legibilidad es pésima, porq todo está separado y
>>>> disperso y con un vistazo no se puede tener idea de lo
>>>> q pasa. Con bloques inline como los de Ruby se podría mejorar esto.
>>>>
>>>
>>> Si el if/elif/else no te vale, igual si que deberias considerar usar
>>> funciones separadas :-O
>>>
>>
>> Ok, lo cual sería mucho más legible que algo como (en un Python
>> Rubizadoribilistizado ;o)
>>
Realmente debería lucir mejor así
{
'k' : do
x = 1; y = 2
end,
'w' : do
x = 3; y = 4
end,
'g' : do
x = 5; y = 6
end,
'xxx' : do
x = 7; y = 8
end,
}[variable].execute()
;o)
> Si viera un código que utilizara eso me cortaria las venas. De pronto
> me encontraria sorprendido de que me aparezan mágicamente las
> variables x e y.
Es la misma magia q ocurre si se ejecuta
exec(
{
'k' : compile('x = 1; y = 2'),
'w' : compile('x = 3; y = 4'),
'g' : compile('x = 5; y = 6'),
'xxx' : compile('x = 7; y = 8')
}[variable])
lo q con la ventaja adicional del chequeo de sintaxis, y ser más
legible (IMO ;o)
> Recuerda que estarías invocando a una función
> devuelta por un diccionario que puede estar definido muy lejos de
> donde se está usando.
>
Creo q hay que hacer una precisión, ahí no se estaría ejecutando una
función, sino un objeto código
>> ... verdad ? Si se da cuenta, utilizando funciones tendríamos q hacer
>> 4 que retornaran una tupla y se le asignaran a x y y. La otra cuestion
>> es la de los parámetros de esas funciones. Generalmente se necesitan
>> cosas en el namespace local para utilizarlas dentro del `switch` y
>> estas hay q pasarlas como parámetros. Claro, se pueden usar las
>> clausuras, pero reflexionemos todos los conceptos q se han mencionado
>> y cuan similares son a lo q nosotros pensamos cuando vamos a tomar uno
>> de varios caminos para tomar una decisión.
>>
>
> El código que se escribe se ha de leer muchas veces. En las
> revisiones, mejoras, correcciones de bugs, ... Prefiero un código que
> se tarda unos segundos más en escribirlo y se tarda varios minutos
> menos en leerlo. Prefiero que uno no se vea tentado a sacrificar esa
> legibilidad ni en los momentos de peor estrés.
>
Correcto, q es más legible, el código inline dentro del diccionario o
el exec (q debe funcionar y es real) con los `compile`s ?
Yo me voy por el primero ;o)
>>
>>>> Claro, q en todos estos casos se pudiera utilizar un objeto de typo
>>>> `code`, la función `compile`, o `exec`, pero el efecto no es el mismo
>>>> ... IMO
>>>
>>> ¿Por el coloreado de sintaxis en el editor?
>>>
>>
>> No, de hecho no uso nada eso, todo lo programo con VIm sin colorcitos :P
>
> :sy on
>
Gracias, pero no lo uso a conciencia ;o)
>> Lo digo porq errores en el código se detectan al compilar hacia .PYC,
>> mientras que errores dentro de una cadena ejecutada con exec se
>> detectan al ejecutar la línea de código del exec (i.e. el hecho de q
>> compile no quiere decir q no está roto ;o). Además, si las
>> continuaciones son «perjudiciales como el goto», no creo q un exec sea
>> más beneficioso, considerando que rompe la secuencia precondición,
>> invariante, postcondición y las buenas prácticas de escritura del
>> código q plantearon Dijkstra, CAR Hoare et al. basados en modelos como
>> CSP, o luego DbC, ... Pero bueno, esa meta-tranca no la sigo para no
>> ponerme demasiado OT
>>
>
> La generación de bytecodes (ficheros .pyc) sólo detecta errores sintácticos.
>
es de lo q hablo
> 4c4-local:~ lasi$ python kk.py
> hola
> m4c4-local:~ lasi$ cat kk.py
> def kk():
> print variable_que_no_existe
>
> print "hola"
> m4c4-local:~ lasi$ pyflakes kk.py
> kk.py:2: undefined name 'variable_que_no_existe'
>
>
> Usar pyflakes o pylint es mejor ;-)
>
... pero eso no analiza las cadenas de los exec, eval & co. ¿o sí?
>>> Creo que esto se empieza a perecer a una lucha dialectica entre si la
>>> tortilla de patata está más buena con cebolla o sin ella :-P
>>
>> Puede ser q ese sea el camino q otros quieran darle a la conversación,
>> yo solo quiero explorar y análizar las capacidades del lenguaje
>> tratando de estar lo menos prejuiciado posible por el hecho de q me
>> gusta, para así poder ser medianamente objetivo y 30% acertado, y
>> tener bien claro cómo es posible mejorarlo ;o)
>>
>
> Es objetivo que esa funcionalidad no está en el lenguaje.
+1
> Es subjetivo
> el hecho de que sea deseable.
+1 ... todo lo q digo parte de mi opinión personal.
> Yo personalmente no la deseo si el
> precio a pagar puede ser la perdida de legibilidad.
>
¿En q sentido se pierde la legibilidad?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
gmane.comp.version-control.subversion.trac.general -
http://feedproxy.google.com/~r/TracGViz-full/~3/SLY6s0RazcA/28067
_______________________________________________
Python-es mailing list
Python-es@python.org
http://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/
