Properties y metodos 'virtuales'

[Ernesto Revilla]

Hola,


----- Original Message -----
From: "Hernan Martinez Foffani" <hernan en orgmf.com.ar>
To: <python-es en aditel.org>
Sent: Saturday, August 31, 2002 11:34 AM
Subject: [Python-es] RE: Properties y metodos 'virtuales'


> > suponed el siguiente ejemplo para Python 2.2:
> >
> > class X(object):
> >     def set_a(self,value):
> >         self._a=value
> >     def get_a(self):
> >         print "leyendo desde X"
> >         return self._a
> >     a=property(get_x,set_x)
> >
> > class Y(X):
> >     # redefinimos solo el get, extendiéndolo
> >     def get_a(self):
> >         print "leyendo desde Y"
> >         return X.get_a(self)
> >
> > y=Y()
> > y.a=20
> > print "y.a es", y.a
> >
> > -> Y.get_a no es llamado. porque al establecer property, se ha asignado
> > directamente una función. Lo que básicamente significa que las llamadas
no
> > son 'virtuales', pero eso va algo en contra de la filosofía de Python.
Yo
> > quiero usarlo en la capa de persistencia, con las propiedades creadas
> > automáticamente, para que el usuario pueda derivar de las clases
> > generadas y meter su propio código en los métodos get y set.
> >
>
> no veo que vaya contra la filosofia de Python.  por el momento
> (no hay una nueva sintaxis) las propiedades se definen en forma
> explicita mediante el builtin, en el momento de la definicion de
> la clase.
Por defecto, todos los métodos definidos en la clase son 'virtuales', pienso
que también debería existir una manera para hacer que los métodos llamados a
partir de un 'property' lo sean. Python es uno (de los pocos) lenguajes,
donde todo es virtual por defecto. Eso no es así ni en Java, ni en C++,
aunque creo que si es así en Smalltalk y Eiffel.

> no es mas sencillo que el usuario agregue la llamada a property?
Me gustaría ocultar ese detalle al programador porque cada vez que redefina
un get o un set tendría que poner de nuevo el property, y ya sé que algunas
veces se lo va a olvidar, y mi tarea es crear la máxima comodidad, claridad
y facilidad al programador. (Ese debería ser la meta de cualquiera que
escriba un componente (librería, paquete, módulo).)

>  class Y(X):
>      # redefinimos solo el get, extendiéndolo
>      def get_a(self):
>          print "leyendo desde Y"
>          return X.get_a(self)
>
>      a = property(get_a, Y.set_a)
>
> en todo caso el usuario ya tiene que llamar a X.get_a(self) en forma
> explicita!
Algunas veces, uno lo tiene que ver así de claro, y para ello necesita otra
persona, como tú (o vos, en argentino), para iluminarle (como a mi) la
mente. Gracias.

> > Así que reformo la sentencia de clase X para usar expresiones lambda de
la
> > siguiente manera:
> >     a=property(lambda self: self.get_x(), lambda self,value:
> > self.set_x(value))
> >
> > ¿Es esa la manera correcta? He leído sobre los métodos __get__, pero no
sé
> > si eso puede servir para algo. (Se supone que se puede heredar de
property
> > para hacer cualquier tipo de cosas.)
>
> property es una clase.  pero no creo que por alli vayas muy lejos.
Todavía no le veo el camino, así que no puedo ver si llega lejos o no. Lo
único que se me ocurre es alguna cosa como esta:

class virtualproperty(property):
    def __init__(self, getmethod=None, setmethod=None, delmethod=None,
doc=''):
        if getmethod: getmethod=eval("lamda self: self.%s()" %
getmethod.func_name)
        if setmethod: setmethod=eval("lamda self: self.%s()" %
setmethod.func_name)
        if delmethod: delmethod=eval("lamda self: self.%s()" %
delmethod.func_name)
        property.__init__(self, getmethod, setmethod, delmethod, doc)

Pero quizá tengas trazón que sea mejor con tratar la creación de los
properties desde las metaclases.

> en resumen, vos estás queriendo que la llamada a property() de la
> subclase se haga directamente, sin intervencion del usuario.
> para ello puedes usar metaclases.
Bueno, habrá que pensarlo y hacerlo con metaclases. La semántica no está
clara con herencia múltiple donde se repiten alguna de las propiedades para
el caso de get, porque sólo puede devolver uno de los valores, creo que el
primero que encuentre es el que sirve.

> > ¿Lo del ObjectDomain R3, no lo ha usado nadie?
>
> yo no.  pero me alegra saber que alguien le esta haciendo buena
competencia
> a Rational.  no se por qué, pero me da la sensación que Rational es a las
> herramientas CASE, lo que Microsoft a los sistemas operativos.
Sí, además por lo visto el Visual Studio Enterprise contiene una copia casi
exacta del Rational Rose (los objetos COM también se llaman Rose.*). Pero me
quería despegar un poco de M$, por ello estoy con Python, y espero que
mediante cosas de ActiveState no pierda la compatibilidad hacia la
plataforma .NET (que ahora mismo no toco).

El tema del ObjectDomain (OD), es que incluye un interprete JPython 2.0 para
poder acceder al meta-modelo, y ya incluye pantillas de generación de código
y también de ingeniería inversa (que sinceramente podría mejorar bastante).
A largo plazo me gustaría poder integrar un editor Python, como IDLE (yo
trabajo con PythonWin) con un entorno de modelado y saltar entre ambos según
necesidad (desde la definición de clase a algún diagrama, y viceversa).

En algún sitio (www.objectsbydesign.com) leí que incluso sería posible crear
diagramas de secuencia mediante trazas creadas por depurador. En algunos
casos esto podría dar más luz sobre qué está pensando en programas que
tengan cierta complejidad.

Saludos cordiales,
Erny



>
> saludos,
> -Hernan
>
> _______________________________________________
> Python-es mailing list
> Python-es en aditel.org
> http://listas.aditel.org/listinfo.py/python-es