[Python-es] Python y/o ruby para no programadores

[lasizoillo]

El día 9 de febrero de 2010 14:09, Olemis Lang (Simelix)
<olemis+py en gmail.com> escribió:
> Solo una precisión ;o)
>
> 2010/2/8 Chema Cortes <pych3m4 en gmail.com>:
>> El día 8 de febrero de 2010 16:39, Olemis Lang (Simelix)
>> <olemis+py en gmail.com> escribió:
>>
>>> pero los bloques de código de Ruby son muy cómodos y potentes (y no
>>> hay nada como eso en Python)
>>
>> Cómodos sí, pero no diría tanto como que no hay nada en python. En
>> python puedes hacer casi lo mismo con iterables, con la posibilidad de
>> usar la sencillez de la comprensión de listas para manejarlos (compara
>> código anidando bloques de código, por ejemplo).
>>
>
> No creo estar completamente de acuerdo. Hay varias cuestiones entre
> ambos enfoques q creo q hay que destacar :
>
>  - Si el tema es sobre el uso de bloques con `each` entonces esto
>     es completamente corecto
>  - Pero los bloques no se limitan necesariamente a eso.
>     - Por ejemplo,
>       en el caso de IO asíncrona muy frecuentemente se utilizan
>       callbacks. En Python la única solución es escribir una
>       función o «clase invocable» (i.e. callable) y pasarla como parámetro
>       a alguna función o mecanismo de registro q tenga la API.
>       Esto puede ser engorroso. En Ruby los casos sencillos pueden
>       ser descritos con un bloque de código inline y queda más legible
>       y menos «verbose» (más conciso).

#Asi a ojo y sin probar

def block(code):
   def inner():
       exec code
   return inner

cosa_asincrona.register(block("print 'no es para tanto'"))
otra_cosa.register(block("""
    for i in range(10):
        print 'no volvere a copiar en clase'
"""))

No lo he probado porque soy feliz definiendo funciones para las
llamadas asincronas. Hay no, perdona, que tambien puedes consumir las
llamadas asincronas con coroutinas:
http://blog.mekk.waw.pl/archives/14-Twisted-inlineCallbacks-and-deferredGenerator.html

>    - 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


> 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?

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