Uso de lambdas y funciones como variables

Prerrequisitos

(Marcar colocando una X entre los corchetes los ítems que ya hiciste, así: "[X]")

[x] Leí las reglas del foro (https://github.com/IIC2233/Syllabus/wiki/3.-Reglas-del-foro-(issues)).
[x] Revisé el compilado de dudas de la tarea y no encontré una issue similar a la mía (click aquí para ir al compilado).
[x] Mi duda no se trata sobre una librería o built-in, ya que eso se pregunta en la issue creada para ello (click aquí para ir a esa issue).
[x] De ser necesario, colocaré código simple que permita explicar mi problema o duda, ya que compartir código de esta evaluación puede ser considerado una falta a la ética.

Duda

Me preguntaba si está permitido el uso de funciones lambda como lambda a,b,c: a+b+c en la tarea.

De manera similar, me pregunto si está permitido definir funciones dentro de otra función del siguiente modo:

def foo():
    # ...
    def bar():
        # ...
    # ...
    bar()

Y por último, me pregunto si está permitido utilizar variables que sean funciones, y en particular si se pueden usar estas variables como argumentos a funciones/propiedades de clases, del siguiente modo:

def foo():
    # ...

def do_twice(funcion: Callable) -> Callable:
    def bar():
        funcion()
        funcion()
    return bar

class Clase:
    def __init__(self, funcion: Callable):
        self.funcion = funcion

foo_twice = do_twice(foo)

clase = Clase(foo_twice)

Hola @lcayazzo !

Vamos por partes;

No puedes usar lambda en esta tarea ya que aún no es parte de los contenidos enseñados y, como se explicíta en el enunciado, están restringidos a los contenidos ya vistos.
Está permitido definir funciones identadas, y utilizar funciones como variables (al fin y al cabo es lo que son).

Dicho esto, me parece importante mencionar que ningún comportamiento que puedas conseguir estructurando tu código de esa forma, es "no-lograble" escribiendo tu código menos anidado. Recuerda que cuando escribes código siempre debes apuntar a un bajo acoplamiento y una alta cohesión.

En tu ejemplo, estás creando una red complicada de conexiones definiendo foo que luego se entrega como argumento a do_twice (que a su vez define bar e intenta llamar dos veces a foo), después le cambias el nombre a foo_twice y se lo pasas como argumento para instanciar la clase Clase, quien lo guarda como una variable de instancia (otra vez, con un nombre distinto). Aunque ninguno de los pasos está prohibido, sí generas un código innecesariamente complicado y acoplado. Recuerda que en esta tarea y sobre todo en las posteriores, los ayudantes deberán leer tu código y ser capaces de entender qué es lo que hace para evaluarte correctamente. En otras palabras, existen mejores formas de abordar el comportamiento que deseas.

Para finalizar, me permito dejarte el mantra de nuestro querido Python🐍:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

IIC2233 / Syllabus

Uso de lambdas y funciones como variables #72

Prerrequisitos

Duda