[Python-es] Análisis sobre Python vs ruby WAS: Python y/o ruby para no programadores

[Olemis Lang (Simelix)]

2010/2/9 lasizoillo <lasizoillo en gmail.com>:
> El día 9 de febrero de 2010 15:52, Olemis Lang (Simelix)
> <olemis+py en 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