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

[Olemis Lang (Simelix)]

2010/2/9 Chema Cortes <pych3m4 en gmail.com>:
> El mar, 09-02-2010 a las 15:01 -0500, Olemis Lang (Simelix) escribió:
>> 2010/2/9 Chema Cortes <pych3m4 en gmail.com>:
>> > Piensa un poco lo que estás diciendo:
>> >
>> > "Crea un bloque "case" de funciones anónimas que se selecciona según
>> > una clave de diccionario". Éso no es más que un "módulo" de python:
>> >
>>
>> Voy a ser sincero y, para poder entender, voy a confesar que no
>> entendí nada del comentario. Al menos yo estaba hablando de casos bien
>> conocidos [1]_ [2]_ [3]_ ... y mencionados por ahí hace mucho tiempo
>> ya ...
>>
[...]
>>
> Lo que venía a decir es que resulta paradójico que tengas que ir
> etiquetando bloques anónimos por la única razón de no querer definirlos
> apropiadamente como funciones.
>

Bueno, puede ser q eso era la intención, pero lo q está escrito es
«Piensa un poco lo que estás diciendo:» y, bueno, espero q haya
quedado claro q somos ya varios los q no hemos pensado bien durante
mucho tiempo, incluyendo la FAQ de Py. Solo eso ;o)

Acerca de los módulos, hay otras cosas más q quería mencionar (y ojalá
tenga tiempo de ampliar el debate, pero si no es hoy será otro día ;o)
:

  - Cual es la diferencia (considerando el ejemplo ;o) entre un diccionario y
    un objeto (e.g. módulo) ? Mi opinión es ninguna, solo q tener un módulo
    para cada switch (q a la postre no es una abstracción de nada, sino más
    bien algo q debería quedar en el plano sintáctico para especificar
flujo del
    programa ;o) es IMHO algo abusivo
  - IMHO las funciones del switch no deben quedar expuestas al riesgo de ser
    remplazadas (monkey-patched ?) al menos a no ser q eso sea la intención,
    (y no pondré ejemplos, pero espero q se comprenda q eso no es lo más
    raro del mundo) puesto a que en ese caso el funcionamiento sería
    impredecible si una librería externa hace unas cuantas modificaciones.
    Ejemplo :

{{{
#!python

# Espero q se concentren en la idea y no en los detalles del ejemplo ;o)

def a(): pass
def b(): pass
def d(): pass

def c(x):
  {'a': a, 'b': b}.get(x, d)()

# En otra parte o módulo

a, d = b, a
}}}

  - El if / elif trabaja en O(n) en el peor caso mientras que el
dict-based switch
    trabaja en O(1)
  - La solución con bloques inline puede ser más eficiente al no tener que
    construir el dict dentro de la llamada de la función ;o)

> Lo de usar un módulo lo ponía como ejemplo donde tener todas las
> funciones agrupadas accesibles por una clave: el nombre de la función.
>

ok, pero me sonó a matar mosquitos con un F-16

>> > Por supuesto que con los bloques de código se puede conseguir que el
>> > código sea más legible y elegante; pero tampoco es para decir que en
>> > python no haya nada parecido o que represente una carencia del
>> > lenguaje.
>>
>> Bueno esto no quiere decir q Python sea más o menos malo. Solo q según
>> el significado de la palabra si no lo tiene es una carencia, ¿no?
>
> Yo lo llamaría "carencia" si hubiera una "necesidad"; como no la hay,
> como mucho lo llamaría una futura "mejora".
>

Haber, en el diccionario de la RAE encuentro (lástima q no haya
permalink :o( ... ) q un uso de `carencia` es

1. f. Falta o privación de algo.

por tanto si Python no tiene bloques inline entonces carece de ellos.
De todas formas, si hay preferencias por otra palabra no hay problemas
. Lo q tiene q quedar claro es q Python no tiene bloques inline

> Espero que haya quedado algo más claro mis comentarios.

;o)

> Yo también eché
> de menos los bloques de código en python, algo que ya usaba
> habitualmente con clipper 5.3 mucho antes de existir ruby.
>

/me using Smalltalk

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Embedding pages? - Trac Users | Google Groups  -
http://feedproxy.google.com/~r/TracGViz-full/~3/-XtS7h-wjcI/e4cf16474aa3cb87