From agtugo en gmail.com  Mon Aug 13 02:02:14 2018
From: agtugo en gmail.com (AGTUGO)
Date: Mon, 13 Aug 2018 01:02:14 -0500
Subject: [Python-es] herencia multiple comportamiento con diferentes
 argumentos
Message-ID: <CACAPgmGReMTej6MXMPZ06eXb8UJAPqndSky7R6SJq0yH=tk3eA@mail.gmail.com>

Estimada Lista de Python en español:

Repasando un poco los conceptos de herencia multiple ya que no la uso mucho
no recuerdo el porque del siguiente comportamiento, no entiendo porque paso
por el iniciador de Second. De antemano muchas gracias. La idea de llamar
los init de las clases Third y Second es pasarle argumentos diferentes y no
tener que modificar Second y Third con **kwargs como argumento.

class First(object):
    def __init__(self):
        print("first")

class Second(First):
    def __init__(self):
        super(Second,self).__init__()
        print("second")

class Third(First):
    def __init__(self):
        super(Third,self).__init__()
        print("third")

class Fourth(Third,Second):
    def __init__(self):
        Third.__init__(self)
#       Second.__init__(self)
        print("Forth")

print(First.__mro__)
print(Second.__mro__)
print(Third.__mro__)
print(Fourth.__mro__)

#//root = tk.Tk()
#//app = Window(root)
#//root.mainloop()

nieto = Fourth()

_________

Salida:

(<class '__main__.First'>, <class 'object'>)
(<class '__main__.Second'>, <class '__main__.First'>, <class 'object'>)
(<class '__main__.Third'>, <class '__main__.First'>, <class 'object'>)
(<class '__main__.Fourth'>, <class '__main__.Third'>, <class
'__main__.Second'>, <class '__main__.First'>, <class 'object'>)
first
second
third
Forth





-- 
Saludos.
AM
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20180813/4c67aad7/attachment.html>

From pych3m4 en gmail.com  Mon Aug 13 04:08:53 2018
From: pych3m4 en gmail.com (Chema Cortes)
Date: Mon, 13 Aug 2018 10:08:53 +0200
Subject: [Python-es] herencia multiple comportamiento con diferentes
 argumentos
In-Reply-To: <CACAPgmGReMTej6MXMPZ06eXb8UJAPqndSky7R6SJq0yH=tk3eA@mail.gmail.com>
References: <CACAPgmGReMTej6MXMPZ06eXb8UJAPqndSky7R6SJq0yH=tk3eA@mail.gmail.com>
Message-ID: <CAAD4gUC8J0n0nPqXkW6eZ_=0kHx746AdGQ_3+vezOPVr9pGzLg@mail.gmail.com>

El lun., 13 ago. 2018 a las 8:02, AGTUGO (<agtugo en gmail.com>) escribió:

> Estimada Lista de Python en español:
>
> Repasando un poco los conceptos de herencia multiple ya que no la uso
> mucho no recuerdo el porque del siguiente comportamiento, no entiendo
> porque paso por el iniciador de Second. De antemano muchas gracias. La idea
> de llamar los init de las clases Third y Second es pasarle argumentos
> diferentes y no tener que modificar Second y Third con **kwargs como
> argumento.
>
> class First(object):
>     def __init__(self):
>         print("first")
>
> class Second(First):
>     def __init__(self):
>         super(Second,self).__init__()
>         print("second")
>
> class Third(First):
>     def __init__(self):
>         super(Third,self).__init__()
>         print("third")
>
> class Fourth(Third,Second):
>     def __init__(self):
>         Third.__init__(self)
> #       Second.__init__(self)
>         print("Forth")
>
> print(First.__mro__)
> print(Second.__mro__)
> print(Third.__mro__)
> print(Fourth.__mro__)
>
> #//root = tk.Tk()
> #//app = Window(root)
> #//root.mainloop()
>
> nieto = Fourth()
>
> _________
>
> Salida:
>
> (<class '__main__.First'>, <class 'object'>)
> (<class '__main__.Second'>, <class '__main__.First'>, <class 'object'>)
> (<class '__main__.Third'>, <class '__main__.First'>, <class 'object'>)
> (<class '__main__.Fourth'>, <class '__main__.Third'>, <class '__main__.Second'>, <class '__main__.First'>, <class 'object'>)
> first
> second
> third
> Forth
>
> Siguiendo los pasos de la ejecución:

- Se crea una instancia de Fourth
- En la inicialización, se "fuerza" la ejecución del método __init__ en
Third
- En el método __init__ de Third, se invoca el método __init__ del
super(Third, self)

¿Quién es "super" aquí? Como 'self' es una instanacia de Fourth, se usa su
MRO: (Fourth, Third, Second, First, object), o sea, super es el siguiente a
Third en la secuencia, que sería Second.

- Se invoca el método __init__ de Second

El problema que se te plantea se conoce por "herencia múltiple
colaborativa". Para que funcione, los métodos invocados han de aceptar
cualquier número de argumentos, ignorando aquellos que no vaya a usar.

Lamentablemente, la herencia múltiple se suele usar más como "mixin" para
encadenar interfaces. Este tipo de uso no debería tener "inicializadores",
o bien usar una estructura de datos común que vendría a ser algo similar a
los argumentos **kwargs de la herencia múltiple colaborativa.

Mi consejo es que siempre uses **kwargs si piensas hacer interfaces que se
combinen por herencia múltiple.

-- 
Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
http://ch3m4.org/blog
Buscador Python Hispano: http://ch3m4.org/python-es
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20180813/f5c329d4/attachment.html>

From agtugo en gmail.com  Mon Aug 13 10:57:55 2018
From: agtugo en gmail.com (AGTUGO)
Date: Mon, 13 Aug 2018 09:57:55 -0500
Subject: [Python-es] herencia multiple comportamiento con diferentes
 argumentos
In-Reply-To: <CAAD4gUC8J0n0nPqXkW6eZ_=0kHx746AdGQ_3+vezOPVr9pGzLg@mail.gmail.com>
References: <CACAPgmGReMTej6MXMPZ06eXb8UJAPqndSky7R6SJq0yH=tk3eA@mail.gmail.com>
 <CAAD4gUC8J0n0nPqXkW6eZ_=0kHx746AdGQ_3+vezOPVr9pGzLg@mail.gmail.com>
Message-ID: <CACAPgmG4zWVZReADyUtdL+ag693b6apZAQZ5SG36v4sRG=REbQ@mail.gmail.com>

Después de estudiar tu respuesta Chema, cómo dices kwargs es necesario. Y
después de revisar la documentación de Python hace referencia a esta
excelente guía
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/

Pone ejemplos de cómo usar adaptadores para clases que no están diseñadas
para ser cooperativas, y el adaptador puede ser la clase base que sea
necesaria. Como dices **kwargs es la única manera.

Si no puedes modificar la clase de la cual quieres heredar de manera
multiple y no esta diseñada para ser cooperativa; pues un adaptador y ya
está.

El lun., 13 de ago. de 2018 3:09 AM, Chema Cortes <pych3m4 en gmail.com>
escribió:

> El lun., 13 ago. 2018 a las 8:02, AGTUGO (<agtugo en gmail.com>) escribió:
>
>> Estimada Lista de Python en español:
>>
>> Repasando un poco los conceptos de herencia multiple ya que no la uso
>> mucho no recuerdo el porque del siguiente comportamiento, no entiendo
>> porque paso por el iniciador de Second. De antemano muchas gracias. La idea
>> de llamar los init de las clases Third y Second es pasarle argumentos
>> diferentes y no tener que modificar Second y Third con **kwargs como
>> argumento.
>>
>> class First(object):
>>     def __init__(self):
>>         print("first")
>>
>> class Second(First):
>>     def __init__(self):
>>         super(Second,self).__init__()
>>         print("second")
>>
>> class Third(First):
>>     def __init__(self):
>>         super(Third,self).__init__()
>>         print("third")
>>
>> class Fourth(Third,Second):
>>     def __init__(self):
>>         Third.__init__(self)
>> #       Second.__init__(self)
>>         print("Forth")
>>
>> print(First.__mro__)
>> print(Second.__mro__)
>> print(Third.__mro__)
>> print(Fourth.__mro__)
>>
>> #//root = tk.Tk()
>> #//app = Window(root)
>> #//root.mainloop()
>>
>> nieto = Fourth()
>>
>> _________
>>
>> Salida:
>>
>> (<class '__main__.First'>, <class 'object'>)
>> (<class '__main__.Second'>, <class '__main__.First'>, <class 'object'>)
>> (<class '__main__.Third'>, <class '__main__.First'>, <class 'object'>)
>> (<class '__main__.Fourth'>, <class '__main__.Third'>, <class '__main__.Second'>, <class '__main__.First'>, <class 'object'>)
>> first
>> second
>> third
>> Forth
>>
>> Siguiendo los pasos de la ejecución:
>
> - Se crea una instancia de Fourth
> - En la inicialización, se "fuerza" la ejecución del método __init__ en
> Third
> - En el método __init__ de Third, se invoca el método __init__ del
> super(Third, self)
>
> ¿Quién es "super" aquí? Como 'self' es una instanacia de Fourth, se usa su
> MRO: (Fourth, Third, Second, First, object), o sea, super es el siguiente a
> Third en la secuencia, que sería Second.
>
> - Se invoca el método __init__ de Second
>
> El problema que se te plantea se conoce por "herencia múltiple
> colaborativa". Para que funcione, los métodos invocados han de aceptar
> cualquier número de argumentos, ignorando aquellos que no vaya a usar.
>
> Lamentablemente, la herencia múltiple se suele usar más como "mixin" para
> encadenar interfaces. Este tipo de uso no debería tener "inicializadores",
> o bien usar una estructura de datos común que vendría a ser algo similar a
> los argumentos **kwargs de la herencia múltiple colaborativa.
>
> Mi consejo es que siempre uses **kwargs si piensas hacer interfaces que se
> combinen por herencia múltiple.
>
> --
> Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
> http://ch3m4.org/blog
> Buscador Python Hispano: http://ch3m4.org/python-es
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> https://mail.python.org/mailman/listinfo/python-es
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20180813/0b54461f/attachment.html>

From pych3m4 en gmail.com  Tue Aug 14 19:40:56 2018
From: pych3m4 en gmail.com (Chema Cortes)
Date: Wed, 15 Aug 2018 01:40:56 +0200
Subject: [Python-es] herencia multiple comportamiento con diferentes
 argumentos
In-Reply-To: <CACAPgmG4zWVZReADyUtdL+ag693b6apZAQZ5SG36v4sRG=REbQ@mail.gmail.com>
References: <CACAPgmGReMTej6MXMPZ06eXb8UJAPqndSky7R6SJq0yH=tk3eA@mail.gmail.com>
 <CAAD4gUC8J0n0nPqXkW6eZ_=0kHx746AdGQ_3+vezOPVr9pGzLg@mail.gmail.com>
 <CACAPgmG4zWVZReADyUtdL+ag693b6apZAQZ5SG36v4sRG=REbQ@mail.gmail.com>
Message-ID: <CAAD4gUB3MR-er+4JLZ-PPoc9xLg=kThJm1B=1BSa2tOiPArjKg@mail.gmail.com>

El lun., 13 ago. 2018 a las 16:58, AGTUGO (<agtugo en gmail.com>) escribió:

> Después de estudiar tu respuesta Chema, cómo dices kwargs es necesario. Y
> después de revisar la documentación de Python hace referencia a esta
> excelente guía
> https://rhettinger.wordpress.com/2011/05/26/super-considered-super/
>
> Pone ejemplos de cómo usar adaptadores para clases que no están diseñadas
> para ser cooperativas, y el adaptador puede ser la clase base que sea
> necesaria. Como dices **kwargs es la única manera.
>
> Si no puedes modificar la clase de la cual quieres heredar de manera
> multiple y no esta diseñada para ser cooperativa; pues un adaptador y ya
> está.
>
>
Si el fin de usar herencia múltiple era tener código más fácil de
reutilizar y mantener, precisamente los adaptadores consiguen el efecto
contrario. En el ejemplo que has puesto, no sólo habría que adaptar el
método __init__, sino también, por si acaso, los demás métodos heredados
como sería el método 'draw'. Además está el problema de las clases
colaborativas a medias, aquellas que usan 'super' para propagar la cadena
de llamadas, pero que en sus métodos no han considerado usar kwargs. Los
adaptadores no sirven para estos casos.

No sabría darte una solución general que valga en todos los casos. Por
comparar, pongo un gist con la reescritura en scala del mismo ejemplo.
Scala no tiene herencia múltiple, por lo que hay que ser explícito en el
orden de llamadas de los métodos heredados. Al menos los errores se
corrigen antes de ejecutar el código:

    https://gist.github.com/chemacortes/f1796931088e406060543894c9f45d52


-- 
Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
https://blog.ch3m4.org
Buscador Python Hispano: http://busca.ch3m4.org
<https://blog.ch3m4.org/pages/busqueda-python-es/>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20180815/7a91dd53/attachment.html>

From bertothunder en gmail.com  Mon Aug 20 06:46:05 2018
From: bertothunder en gmail.com (Alberto Curro)
Date: Mon, 20 Aug 2018 11:46:05 +0100
Subject: [Python-es] pregunta rapida sobre RotatingFileHandler
In-Reply-To: <CACUP1u9X99t5T+GjPw=Xy5M1n+anFALH40m+0K_quRh5e6VuhQ@mail.gmail.com>
References: <CACUP1u9X99t5T+GjPw=Xy5M1n+anFALH40m+0K_quRh5e6VuhQ@mail.gmail.com>
Message-ID: <CA+8JusuQ9AjTL4CAYy2dt_p8gtVKMHtSovOaK_6ETVHdBukEpg@mail.gmail.com>

El sáb., 17 mar. 2018 a las 14:45, Jose Caballero (<jcaballero.hep en gmail.com>)
escribió:

> Hola,
>
> pregunta: ?alguien sabe que pasa si se intenta escribir un mensaje de
> "log" a la vez que el RotatingFileHandler esta rotando el fichero?
>
> Tenemos una aplicacion que usa el logrotate.d standard de linux. Pero
> para evitar problemas, primero se mata el proceso, se hace la
> rotacion, y luego se reinicia el proceso.
>
> Me gustaria saber si el handler RotatingFileHandler me puede evitar
> esos problemas.
> Entiendo que internamente hace tambien un cambio en el "file descriptor".
> Pero no tengo claro que pasa si se intenta escribir justo cuando se
> esta haciendo la rotacion.
>

 El github de CPython te habría dado la solución a tus dudas:

https://github.com/python/cpython/blob/master/Lib/logging/handlers.py

Si te fijas, en la clase BaseRotatingHandler comprueba si debe hacer un
rollover (rotate) durante el emit. Si el rollover debe hacerse, se aplica
un bloqueo por el subsistema logging, hace el rollover, y después escribe.

Como bien te ha dicho Chema en otro reply, la libreria logging de python es
thread-safe debido a que hace los locks por tí.


> Cualquier comentario, o mejor aun link a documentacion, es mas que
> bienvenido.
>

docs.python.org, siempre.


> Saludos,
> Jose
>
> P.D. perdon por la falta de tildes. Teclado gringo.
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> https://mail.python.org/mailman/listinfo/python-es
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20180820/d4658258/attachment.html>

From agtugo en gmail.com  Wed Aug 22 22:45:35 2018
From: agtugo en gmail.com (AGTUGO)
Date: Wed, 22 Aug 2018 21:45:35 -0500
Subject: [Python-es] herencia multiple comportamiento con diferentes
 argumentos
In-Reply-To: <CAAD4gUB3MR-er+4JLZ-PPoc9xLg=kThJm1B=1BSa2tOiPArjKg@mail.gmail.com>
References: <CACAPgmGReMTej6MXMPZ06eXb8UJAPqndSky7R6SJq0yH=tk3eA@mail.gmail.com>
 <CAAD4gUC8J0n0nPqXkW6eZ_=0kHx746AdGQ_3+vezOPVr9pGzLg@mail.gmail.com>
 <CACAPgmG4zWVZReADyUtdL+ag693b6apZAQZ5SG36v4sRG=REbQ@mail.gmail.com>
 <CAAD4gUB3MR-er+4JLZ-PPoc9xLg=kThJm1B=1BSa2tOiPArjKg@mail.gmail.com>
Message-ID: <CACAPgmHfu31CEH-xsE+tGs-Tr4C082tYrt6oZkVyU+-K2McKdA@mail.gmail.com>

La implementación en scala se puede leer muy fácilmente sin conocer el
lenguaje. Es interesante ver cómo hay varios lenguajes para la jvm, lástima
que jython nunca despegó del todo. de conclusión de esto es que no me
encanta super() ya que solo es un next del mro casi como si fuera un
iterador. Veré cómo lo hace smalltalk ya que siempre es interesante ver
cómo implementan cosas.

El caso donde me parece útil usar un adaptador, es cuando usas una clase
que no puedes modificar y aunque no haya sido pensada así .

class Moveable:
    def __init__(self, x, y):
        self.x = x
        self.y = y
    def draw(self):
        print('Drawing at position:', self.x, self.y)



class MoveableAdapter(Root):
    def __init__(self, x, y, **kwds):
        self.movable = Moveable(x, y)
        super().__init__(**kwds)
    def draw(self):
        self.movable.draw()
        super().draw()

class MovableColoredShape(ColoredShape, MoveableAdapter):
    pass

MovableColoredShape(color='red', shapename='triangle',
                    x=10, y=20).draw()

Solo me parece útil cuando por alguna razón no puedes modificar esas
clases. Por ejemplo: trabajo cooperativo o arquitectura dependiente de la
clase que no quieres modificar. No sé si sea lo más elegante pero me parece
práctico.

____________________________________________________________________
El mar., 14 de ago. de 2018 6:41 PM, Chema Cortes <pych3m4 en gmail.com>
escribió:

>
>
> El lun., 13 ago. 2018 a las 16:58, AGTUGO (<agtugo en gmail.com>) escribió:
>
>> Después de estudiar tu respuesta Chema, cómo dices kwargs es necesario. Y
>> después de revisar la documentación de Python hace referencia a esta
>> excelente guía
>> https://rhettinger.wordpress.com/2011/05/26/super-considered-super/
>>
>> Pone ejemplos de cómo usar adaptadores para clases que no están diseñadas
>> para ser cooperativas, y el adaptador puede ser la clase base que sea
>> necesaria. Como dices **kwargs es la única manera.
>>
>> Si no puedes modificar la clase de la cual quieres heredar de manera
>> multiple y no esta diseñada para ser cooperativa; pues un adaptador y ya
>> está.
>>
>>
> Si el fin de usar herencia múltiple era tener código más fácil de
> reutilizar y mantener, precisamente los adaptadores consiguen el efecto
> contrario. En el ejemplo que has puesto, no sólo habría que adaptar el
> método __init__, sino también, por si acaso, los demás métodos heredados
> como sería el método 'draw'. Además está el problema de las clases
> colaborativas a medias, aquellas que usan 'super' para propagar la cadena
> de llamadas, pero que en sus métodos no han considerado usar kwargs. Los
> adaptadores no sirven para estos casos.
>
> No sabría darte una solución general que valga en todos los casos. Por
> comparar, pongo un gist con la reescritura en scala del mismo ejemplo.
> Scala no tiene herencia múltiple, por lo que hay que ser explícito en el
> orden de llamadas de los métodos heredados. Al menos los errores se
> corrigen antes de ejecutar el código:
>
>     https://gist.github.com/chemacortes/f1796931088e406060543894c9f45d52
>
>
> --
> Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
> https://blog.ch3m4.org
> Buscador Python Hispano: http://busca.ch3m4.org
> <https://blog.ch3m4.org/pages/busqueda-python-es/>
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> https://mail.python.org/mailman/listinfo/python-es
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20180822/3c3be902/attachment.html>

From pych3m4 en gmail.com  Thu Aug 23 06:21:51 2018
From: pych3m4 en gmail.com (Chema Cortes)
Date: Thu, 23 Aug 2018 12:21:51 +0200
Subject: [Python-es] herencia multiple comportamiento con diferentes
 argumentos
In-Reply-To: <CACAPgmHfu31CEH-xsE+tGs-Tr4C082tYrt6oZkVyU+-K2McKdA@mail.gmail.com>
References: <CACAPgmGReMTej6MXMPZ06eXb8UJAPqndSky7R6SJq0yH=tk3eA@mail.gmail.com>
 <CAAD4gUC8J0n0nPqXkW6eZ_=0kHx746AdGQ_3+vezOPVr9pGzLg@mail.gmail.com>
 <CACAPgmG4zWVZReADyUtdL+ag693b6apZAQZ5SG36v4sRG=REbQ@mail.gmail.com>
 <CAAD4gUB3MR-er+4JLZ-PPoc9xLg=kThJm1B=1BSa2tOiPArjKg@mail.gmail.com>
 <CACAPgmHfu31CEH-xsE+tGs-Tr4C082tYrt6oZkVyU+-K2McKdA@mail.gmail.com>
Message-ID: <CAAD4gUBqi119eYKNNb7Rr=q2NTyasdCEH2kTDFWzHKMiwr_Zrw@mail.gmail.com>

El jue 23/08/2018, 4:46, AGTUGO <agtugo en gmail.com> escribió:
>
> La implementación en scala se puede leer muy fácilmente sin conocer el
lenguaje. Es interesante ver cómo hay varios lenguajes para la jvm, lástima
que jython nunca despegó del todo. de conclusión de esto es que no me
encanta super() ya que solo es un next del mro casi como si fuera un
iterador. Veré cómo lo hace smalltalk ya que siempre es interesante ver
cómo implementan cosas.
>
> El caso donde me parece útil usar un adaptador, es cuando usas una clase
que no puedes modificar y aunque no haya sido pensada así .
>
> class Moveable:
>     def __init__(self, x, y):
>         self.x = x
>         self.y = y
>     def draw(self):
>         print('Drawing at position:', self.x, self.y)
>
>
>
> class MoveableAdapter(Root):
>     def __init__(self, x, y, **kwds):
>         self.movable = Moveable(x, y)
>         super().__init__(**kwds)
>     def draw(self):
>         self.movable.draw()
>         super().draw()
>
> class MovableColoredShape(ColoredShape, MoveableAdapter):
>     pass
>
> MovableColoredShape(color='red', shapename='triangle',
>                     x=10, y=20).draw()
>
> Solo me parece útil cuando por alguna razón no puedes modificar esas
clases. Por ejemplo: trabajo cooperativo o arquitectura dependiente de la
clase que no quieres modificar. No sé si sea lo más elegante pero me parece
práctico.

Tal como te decía, el adaptador debe adaptar todos los métodos, no basta
con el método __init__.

Imagina que ColoredShape cambia la signatura del método draw y que
MovableColoredShape lo defines al revés:

class MovableColoredShape( MoveableAdapter, ColoredShape ):
     pass

Cuando el adaptador invoque el método draw del super dará error, porque la
clase ColoredShape espera argumentos que no le estaría pasando.

>
> ____________________________________________________________________
> El mar., 14 de ago. de 2018 6:41 PM, Chema Cortes <pych3m4 en gmail.com>
escribió:
>>
>>
>>
>> El lun., 13 ago. 2018 a las 16:58, AGTUGO (<agtugo en gmail.com>) escribió:
>>>
>>> Después de estudiar tu respuesta Chema, cómo dices kwargs es necesario.
Y después de revisar la documentación de Python hace referencia a esta
excelente guía
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/
>>>
>>> Pone ejemplos de cómo usar adaptadores para clases que no están
diseñadas para ser cooperativas, y el adaptador puede ser la clase base que
sea necesaria. Como dices **kwargs es la única manera.
>>>
>>> Si no puedes modificar la clase de la cual quieres heredar de manera
multiple y no esta diseñada para ser cooperativa; pues un adaptador y ya
está.
>>>
>>
>> Si el fin de usar herencia múltiple era tener código más fácil de
reutilizar y mantener, precisamente los adaptadores consiguen el efecto
contrario. En el ejemplo que has puesto, no sólo habría que adaptar el
método __init__, sino también, por si acaso, los demás métodos heredados
como sería el método 'draw'. Además está el problema de las clases
colaborativas a medias, aquellas que usan 'super' para propagar la cadena
de llamadas, pero que en sus métodos no han considerado usar kwargs. Los
adaptadores no sirven para estos casos.
>>
>> No sabría darte una solución general que valga en todos los casos. Por
comparar, pongo un gist con la reescritura en scala del mismo ejemplo.
Scala no tiene herencia múltiple, por lo que hay que ser explícito en el
orden de llamadas de los métodos heredados. Al menos los errores se
corrigen antes de ejecutar el código:
>>
>>     https://gist.github.com/chemacortes/f1796931088e406060543894c9f45d52
>>
>>
>> --
>> Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
https://blog.ch3m4.org
>> Buscador Python Hispano: http://busca.ch3m4.org
>> _______________________________________________
>> Python-es mailing list
>> Python-es en python.org
>> https://mail.python.org/mailman/listinfo/python-es
>
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> https://mail.python.org/mailman/listinfo/python-es
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20180823/8c418aaa/attachment.html>