El día 11 de abril de 2011 10:48, "Arturo Muñoz T." <[email protected]> escribió: > Si me serviria ese codigo, pero mi duda sería mas bien, ¿qué sería mas > general, mas simple o mas bello?. > Me ha pasado que escribo la función que recibe una lista de palabras, pero > no me gusta del todo. Y luego escribo > para que solo reciba un palabra, no se decidirme por cual. Las dos me > solucionan el problema. Pero... > mi balanza esta en 50% y 50%. Por un lado pienso que tener una función que > solo recibe una palabra y usar > comprension de listas despues es mas general. Pero despues pienso que tener > una funcion que recibe una lista > es mas general. Tal vez es una tontería mi duda. >
La única respuesta válida es que aprendas a convivir con la duda. Todas las opciones son buenas y malas al mismo tiempo. Voy a poner ejemplos para explicarme: Opción de uno en uno ================= Tienes una función que recibe una palabra y tras usar un api devuelve un elemento. Es simple y fácil de probar. Si tienes que llamarla 100 veces, la llamas 100 veces y arreglado. Ya sea con compresión de listas o un simple bucle for. Opción que recibe una lista y devuelve una lista ==================================== Internamente hace dos cosas. Iterar la lista y hacer el funcionamiento de cada una de sus unidades internamente. Puede resultar un poco feo generar una lista de un solo elemento cuando solo quieres procesar un elemento. Pero tiene la ventaja de que si ese api que consumes, el día de mañana permite hacer procesamiento por lotes, podrás hacer uso de esa funcionalidad sin problemas. Eso evitara muchas latencias y parseos. Pero si pasas un string que va a ser tratado como una lista, la función se pondrá a iterar cada una de sus letras. Pudiéndote encontrar con errores inesperados. Opción híbrida =========== Aparentemente resolvemos el problema del punto anterior al detectar mágicamente si llamamos la función con un solo parámetro o si lo llamamos con varios, por lo que las llamadas quedarían más limpias. Por desgracia perdemos algunas funcionalidades que hasta ahora no nos habíamos dado cuenta que teníamos. En el primer caso podemos mandar cualquier cosa que luego se comporte como una cadena. En el segundo caso podríamos usar cualquier cosa que fuese iterable o que se comportase como una lista (cuidado, una cadena entra en este grupo). Pero ahora, al hacer una lógica interna perdemos esta funcionalidad. Con este cambio es posible que para pasar el resultado de un orm tengas que hacer una conversión a lista o alguna otra pega. Esto añadiría tener que hacer las conversiones que queriamos evitarnos hacer. Como ves, decidas lo que decidas, te van a asaltar las dudas y te va a quedar la sensación de que te has podido equivocar. Así que mi recomendación es hacerlo lo más simple posible para que si realmente ves que te has equivocado ya habrá tiempo de meter complejidades en el futuro. Si ahora mismo no hay opción de usar procesos batch para aglutinar varias peticiones en una sola llamada, elegiría la primera opción. Se la ve simple y poco propensa a cometer errores al utilizarla. Pero bueno, como en la apreciación de la belleza, esto es solo mi opinión personal ;-) Saludos: Javi _______________________________________________ Python-es mailing list [email protected] http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
