[pyar] Maybe Metaprogramming?
Emiliano Reynares
reynares.emiliano en gmail.com
Vie Sep 18 13:12:20 ART 2015
De capo nada, pero quedó clarisimo
Saludos!
--
Emiliano
-----------------------------
Emiliano
2015-09-18 12:19 GMT-03:00 Gustavo Ibarra <ibarrags en gmail.com>:
> 2015-09-18 12:14 GMT-03:00 Gustavo Ibarra <ibarrags en gmail.com>:
> > 2015-09-17 20:03 GMT-03:00 Emiliano Reynares <
> reynares.emiliano en gmail.com>:
> >> Gustavo,
> >>
> >> Las clases abstractas en Python realmente impiden la creación de
> instancias?
> >> O en realidad fuerzan a que ciertos métodos (los abstractos) sean
> >> implementados por las subclases "concretas"? Ah, me olvide de decir que
> >> estoy usando Python3
> >
> > Emiliano, respondo hasta donde yo entiendo(me atajo por que quizás
> > este pifiando)..
> >
> > Al margen del lenguaje Python, estos concepto como el de "clase
> > abstracta" sirven para pensar como sera el modelo de clases( sus
> > métodos, responsabilidades,etc!) a la hora de programar el
> > requerimiento. Creo que en la teoría no existen, pero sirven acomodar
> > los tantos y entender(¿estandarizar?) mejor que y como se programa
> > "algo" entre varias personas.
> > Es como decís, los metodos de estas clases son los que terminan siendo
> > "abstracto" y cada clase de tu árbol sabrá(lo programaras) que método
> > implementar( o no ). Sospecho que en esto ultimo también se cumple en
> > Python, de todas maneras hasta donde te entendí, tu necesidad es un
> > tema de diseño de clases(responsabilidades) que del lenguaje en si.
> > Por que si un objeto de una clase no puede ser instanciado, esta puede
> > avisar "no esto disponible para instanciarme"
>
> buscando encontré esto "Unable to create an instance of abstract class"
>
> http://stackoverflow.com/questions/13646245/is-it-possible-to-make-abstract-classes-in-python
> (si entendiste mi anterior mensaje sos un capo, por que lo escribí
> para la mierda)
>
> >
> > En tu lugar me inclinaría por algo por el estilo
> > https://docs.python.org/2/library/abc.html que seguro ya lo viste.
> > (horrible el nombre de la clase ABCs, ¿no?)
> >
> >> Emiliano
> >>
> >> 2015-09-17 19:48 GMT-03:00 Emiliano Reynares <
> reynares.emiliano en gmail.com>:
> >>>
> >>> Gracias por las respuestas, me han clarificado varias cosas.
> >>> Sin embargo, tengo que aclarar que el bindeo de métodos necesito
> hacerlo
> >>> sobre las intancias, no sobre las clases. Siguiendo el ejemplo
> anterior,
> >>> algunos individuos de la clase A tienen bindeados métodos
> implementados por
> >>> la clase B; pero otros individuos podrían tener bindeados métodos
> >>> implementados en una clase C.
> >>> Desde el punto de vista OOP, ya se que es extraño lo que intento
> hacer, el
> >>> tema es que estoy intentando implementar un paradigma completamente
> distinto
> >>> con los elementos actualmente disponibles en Python.
> >>>
> >>> Saludos!
> >>>
> >>> Emiliano
> >>>
> >>> 2015-09-17 13:42 GMT-03:00 Joaquin Duo <joaduo en gmail.com>:
> >>>>
> >>>>
> >>>> 2015-09-17 12:35 GMT-03:00 Emiliano <reynares.emiliano en gmail.com>:
> >>>>>
> >>>>> Lo he visto, solo que seguiria sin poder impedir que sea instanciada
> la
> >>>>> clase de la cual obtengo los métodos a bindear. O estoy equivocado?
> >>>>
> >>>>
> >>>> Es difícil evitar que el programador haga lo que se de le de la gana.
> >>>> Pero si tu idea es evitar malas prácticas, entonces podría generar una
> >>>> excepción en __init__ "raise TypeError('no instanciable')
> >>>> Supongo que podrías hacer una clase padre para todas las clases no
> >>>> instanciables? (entonces heredan init)
> >>>>
> >>>>
> >>>>>
> >>>>> Emiliano
> >>>>> ________________________________
> >>>>> De: Daniel Moisset
> >>>>> Enviado el: 17/09/2015 12:25 p.m.
> >>>>> Para: Python Argentina
> >>>>> Asunto: Re: [pyar] Maybe Metaprogramming?
> >>>>>
> >>>>> Algo como
> >>>>>
> http://stackoverflow.com/questions/8544983/dynamically-mixin-a-base-class-to-an-instance-in-python
> >>>>> te sirve?
> >>>>>
> >>>>> 2015-09-17 12:15 GMT-03:00 Emiliano Reynares
> >>>>> <reynares.emiliano en gmail.com>:
> >>>>>>
> >>>>>> Gente,
> >>>>>>
> >>>>>> Tengo una consulta un poco extraña que hacerles pero espero me
> puedan
> >>>>>> orientar. Lo que necesito es definir una estructura que me permita
> agrupar e
> >>>>>> implementar un conjunto de métodos, los cuales serán "bindeados" a
> un
> >>>>>> individuo que pertenece a una clase distinta, en tiempo de
> ejecución.
> >>>>>> Por el momento lo que se me ha ocurrido es agrupar los métodos a ser
> >>>>>> "bindeados" en una clase. Luego defino un método que permite
> bindearlos a un
> >>>>>> instancia de una clase diferente. Algo así:
> >>>>>>
> >>>>>> class A:
> >>>>>> def bind_methods(self, cls):
> >>>>>> pass
> >>>>>>
> >>>>>> class B:
> >>>>>> def b1(self):
> >>>>>> pass
> >>>>>>
> >>>>>> def b2(self):
> >>>>>> pass
> >>>>>>
> >>>>>> Luego, puedo hacer:
> >>>>>>
> >>>>>> foo = A()
> >>>>>> foo.bind_methods(B)
> >>>>>>
> >>>>>> La implementación la omito para no hacer más largo el mail, pero
> tengo
> >>>>>> eso funcionando. Sin embargo, dudo bastante que sea la manera más
> elegante
> >>>>>> de implementar lo que estoy necesitando.
> >>>>>> Primero, necesitaría que la clase en la cual agrupo los métodos a
> >>>>>> "bindear" (clase B del ejemplo) no pueda ser instanciada. Aún
> cuando pudiera
> >>>>>> lograr eso, el argumento "self" de los métodos definidos en ese
> contexto es
> >>>>>> muy confuso (aunque luego funciona perfectamente al ser "bindeado"
> a la
> >>>>>> instancia).
> >>>>>> Alguna sugerencia/recurso que pueda consultar para conseguir una
> >>>>>> implementación más elegante?
> >>>>>> Espero haber sido claro,
> >>>>>>
> >>>>>> Saludos!
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Emiliano Reynares
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Daniel F. Moisset - Technical Leader
> >>>>> www.machinalis.com
> >>>>> Skype: @dmoisset
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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/20150918/d7cfca8f/attachment-0001.html>
More information about the pyar
mailing list