[pyar] función con valores de retorno distintos

[Matias Graña]

Gracias!
Pensé en algo así y está lindo, pero todo el programa es cortito y creo que
no vale la pena extenderlo con nuevas clases. Esta es para mí LA solución
en algo más complejo.

El punto central para mí es: es buena o mala práctica tener un método cuyos
valores de retorno cambian (cambia la cantidad y/o los tipos) en función de
los parámetros?

-- Matías Graña


2014-07-29 11:39 GMT-03:00 Andres Riancho <andres.riancho en gmail.com>:

> Capaz podes meter todo dentro de un objeto "Linea", devolver siempre
> Linea(s) y sobre ellas hacer:
>
> linea.get_header() => None, lista, string
> linea.get_header_type() => Alguno de una lista de [NO_HEADER,
> HEADER_LIST, HEADER_STRING]
>
> Y despues podrías en tu codigo tener algo que en base al tipo y al
> header lo procese.
>
> FMAP = {NO_HEADER: funcion_a,
>               HEADER_LIST: funcion_b,
>               HEADER_STRING: funcion_c}
>
> def procesa_lineas(linea):
>     return FMAP[linea.get_header_type()](linea)
>
>
> 2014-07-29 11:28 GMT-03:00 Matias Graña <matias.alejo en gmail.com>:
> > Hola;
> > tengo una función que lee un archivo, hace alguna cosa y devuelve el
> > contenido separado por líneas y, eventualmente, separando una línea (o
> más)
> > de headers.
> > Se puede hacer así (versión simplificada):
> >
> > def _get_lines(infile, header_lines=1):
> >     with open(infile, 'r') as data:
> >         ret = [blabla(line) for line in data]
> >     header = None if not header_lines else ret[0] if header_lines == 1
> else
> > ret[:header_lines]
> >     return header, ret[header_lines:]
> >
> > Eso se llama con
> > header, lines = _get_lines(infile)
> > El punto es que header puede ser None, un str o una lista de str, en
> función
> > del valor de header_lines. La pregunta es (y es más amplia que este
> ejemplo
> > puntual) si es razonable que los valores de retorno de una función
> cambien
> > el tipo de esta manera.
> > Esta forma de hacerlo tiene la ventaja de que los casos de uso típico
> van a
> > ser con header_lines = 0 o 1 y entonces en esos casos es cómodo. Pero si
> en
> > algún momento cambia algo y header_lines debe ser > 1, hay que cambiar el
> > código un poco más que si en el return tuviera
> >
> > return ret[:header_lines], ret[header_lines:]
> >
> > Otra opción, que tiene sus pros y sus contras también, es
> >
> > return tuple(ret[:header_lines]) + (ret[header_lines:],)
> >
> > Eso hace que deba llamarse con
> >
> > lines = _get_lines(infile, header_lines=0)
> > header, lines = _get_lines(infile, header_lines=1)
> > header1, header2, lines = _get_lines(infile, header_lines=2)
> >
> > etc. Acá lo que cambia es la cantidad de datos a devolver, y también
> puede
> > ser propenso a errores. En python3 sería un poco más sencillo, porque
> puedo
> > devolver directamente tuple(ret), sin calentarme por header_lines, y
> obligar
> > al llamado a que sea del estilo de
> >
> > header, *lines = _get_lines(infile)
> >
> > Lamentablemente, python3 no es una posibilidad acá. Imagino que no hay
> una
> > única manera correcta de hacer las cosas, pero argumentos a favor o
> encontra
> > de estas opciones son bienvenidos.
> >
> > Gracias!
> >
> > -- Matías Graña
> >
> > _______________________________________________
> > pyar mailing list pyar en python.org.ar
> > http://listas.python.org.ar/listinfo/pyar
> >
> > PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
> >
> > La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> > Argentina - http://www.usla.org.ar
>
>
>
> --
> Andrés Riancho
> Project Leader at w3af - http://w3af.org/
> Web Application Attack and Audit Framework
> Twitter: @w3af
> GPG: 0x93C344F3
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140729/32e9b041/attachment.html>