[pyar] [video] En Python tenemos nombres, no variables.

[Luis Masuelli]

Lo de los metodos para mi tiene una desventaja en Python respecto de, por ejemplo, PHP (no me golpeen, suelo ser el primero en putear contra PHP y los frameworks que le conozco). En PHP uno puede interceptar el hecho de invocar un metodo usando __call() (mientras que el __call__ de Python equivale al __invoke de PHP). Y es que es cierto que los metodos no son tales sino simples funciones "atadas" a una instancia (literalmente o es un UnboundMethod con o sin instancia, o un objeto Function). Tonces un dia me complique porque necesitaba un __call pero en Python, y el __call__ no resultaba equivalente. Lo que termine haciendo es algo similar a las librerias de webservices que se usan por ejemplo para pegarle la la API de Amazon (no me acuerdo cual era la libreria) que cada vez que le pedias un atributo, te devolvia un callable que (cuando lo invocaba(*a, **kwa)) hacia la peticion con un metodo con el nombre que se uso para pedir el atributo (el nombre era pasado al constructor de ese callable). Con esa solucion salia otro problema: si yo queria implementar __get() por un lado y __call por el otro ¿como lo distinguia? porque python solo tiene __getattr__.
Quizas esa no-diferencia entre pedir un metodo no existente (__call() implementando __getattr__ y __call__ sobre el objeto obtenido) o pedir un atributo (__get() usando __getattr__()) podria ser un trade-off del dinamismo que tiene python en cuanto a lo de las clases.
Lo bueno que me cae es que uno puede hacer:
class A:    miembro = "Esta"
A.__class__ = A
Y por fruta que parezca el interprete no se rompe ni nada (y consultar A.__class__ == A da verdadero). En este sentido no cuesta mucho entender como un objeto clase puede tener de clase a sí mismo. El mareo marca ninja se lo pega uno cuando piensa en terminos estructurados no teniendo acceso a las metaclases (si mal no recuerdo uno no puede acceder a las metaclases en Delphi aunque pueda tener variables de clase).
Date: Thu, 5 Jun 2014 11:44:52 -0300
From: fpelliccioni en gmail.com
To: pyar en python.org.ar
Subject: Re: [pyar] [video] En Python tenemos nombres, no variables.




2014-06-05 11:40 GMT-03:00 Fernando Pelliccioni <fpelliccioni en gmail.com>:




2014-06-05 11:38 GMT-03:00 Claudio Freire <klaussfreire en gmail.com>:


2014-06-05 10:45 GMT-03:00 Alejandro Santos <listas en alejolp.com>:



> 2014-06-05 15:41 GMT+02:00 Alejandro Santos <listas en alejolp.com>:

>>

>> Y esto viene porque si tenes un objeto de clase Clase, donde Clase es

>> un objeto, no podés tener una Clase con clase Clase, tenés que tener

>> una "meta-clase" que sea la progenitora de tu Clase, por ejemplo

>> CClase. Y lo mismo CClase, es un objeto, con clase CCClase.

>>

>

> (sigo)

>

> Es una definición recursiva estándar. En general no podés definir un X

> diciendo "X es un X", tenés que expresarlo en términos de otra cosa

> más general.

>

> (a diferencia de la RAE que cuando buscas "cosas" te dice "es el

> plural de cosa" y "cosa" te dice "es el singular de cosas")



Claro que se puede. Es la idea detrás de los representantes de clases

de equivalencia (algo de matemática por si no te suena).



La clase "Clase" es una clase de equivalencia. El objeto que vos tomás

como la clase "Clase" (que obtenés con type) es sólo un objeto dentro

de esa clase que lo representa.



Clase es una Clase. Son la misma palabra, pero no el mismo concepto.

Uno es un objeto. El otro es una clase de equivalencia de objetos.





2014-06-05 10:41 GMT-03:00 Alejandro Santos <listas en alejolp.com>:

> En la facultad tuve una matería que se llamaba "OOP" y que uno de los

> temas era "Teoría de Objetos", donde mi profesor contó esta recursión

> infinita con infinito+1 en nil/null/Null.

>

> Y esto viene porque si tenes un objeto de clase Clase, donde Clase es

> un objeto, no podés tener una Clase con clase Clase, tenés que tener

> una "meta-clase" que sea la progenitora de tu Clase, por ejemplo

> CClase. Y lo mismo CClase, es un objeto, con clase CCClase.





Está equivocado:



Python 2.7.6 (default, Nov 21 2013, 15:55:38) [GCC] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> class C:

...    pass

...

>>> type(C)

<type 'classobj'>

>>> type(type(C))

<type 'type'>

>>> type(type(type(C)))

<type 'type'>

>>>



No *tenés* que tener una meta-meta-clase, porque evidentemente Python

no la tiene.



La clase "type" acá está definida por fuera del lenguaje. En Smalltalk

pasa lo mismo, y no hay nada más OOP que Smalltalk.



¿Cómo se representa eso en la computadora? No importa. En el lenguaje,

el tipo de una clase es Clase (type acá porque está en inglés) y la

clase de Clase es Clase también. Puede sonar raro, pero tiene sentido,

pues la clase y la meta-clase que mencionás se comportan idéntico, así

que no pueden ni necesitan ser diferenciadas. Porque el tipo de algo

como lo ves dentro de un programa es un objeto, no una clase. No podés

hacer type() de una clase, porque la clase no es un objeto (es un

grupo de objetos similares), es algo conceptual. No es parte del

lenguaje.



Anotando a Kay:



1. Todo es un objeto (No una clase)

2. Los objetos se comunican enviando y recibiendo mensajes (métodos -

que son objetos a su vez).

3. Los objetos tienen memoria (formada por objetos - no necesariamente

no-vacía, ojo).

4. Todo objeto **es una instancia de una clase** (o sea, los objetos

se dividen en clases de objetos de similar comportamiento, es un orden

conceptual, no hay variedad infinita de comportamiento - y el

comportamiento es un objeto, o sea, hay un objeto que representa a la

clase en su conjunto - ese objeto, también, tiene un comportamiento

discretamente clasificado ).

5. La clase contiene el comportamiento compartido de sus instancias

(la clase pues tiene objetos que describen el comportamiento de sus

instancias - los métodos en sí mismos)

6. La ejecución de un programa, el control pasa al primer objeto (el

famoso Main) y el resto es tratado como el mensaje (los argumentos)



Luego, si un objeto tiene el comportamiento de una clase, lo que

sucede con los representantes de clase, entonces la clase de ese

objeto clase es la clase misma, pues tiene el mismo comportamiento. Se

comporta como Clase. Qué clase es en particular está representando

está definido en la memoria del objeto Clase, que es parte de la

*instancia*. Nada impide pues que la clase de un objeto sea

representado por el objeto mismo, si el comportamiento de las

instancias es uniforme y es el comportamiento de una clase.



Completamente consistente. Espero que claro también.

_______________________________________________

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



(TOTAL-OT)
Bertrand Meyer nos mata a todos si escucha que dicen que su lenguaje no es OO ;)


Creo que si hablamos de objetos, tenemos que ir a la fuente, pero a la verdadera fuente, Simula.


Aquí alguien pudo rescatar el manual original.	http://www.edelweb.fr/Simula/#7


Y aquí las definiciones basicas	http://www.edelweb.fr/Simula/scb-1.pdf


Yo me pregunto, ¿qué significa paradigma de objetos puro? O mejor, ¿qué significa objeto?¿C es un lenguaje orientado a objetos (sea lo que sea que signifique)? 

Creo que la mayoría vamos a responder que No. Sin embargo, agarro cualquiera de los Estándares de C (89, 99, 11) y veo la palabra "objeto" por todos lados.

No con esto quiero decir que C sea un lenguaje OO, sino, que "objeto" puede significar cosas diferentes.
O sea, que cada uno tome la definición de "objeto" que se le antoje :)

Yo me quedo con una definición un poco mas práctica, de Alex Stepanov, que básicamente es algo parecido a: "Object is a value residing in memory". Simple y práctica, ya que usamos computadoras y éstas tienen memoria (si alguien conoce algún aparato computacional que no use memoria me avisa :)). 

(Para una definición mas "formal" ver Elements Of Programming, pag.4)
Me encantaría ver algún paper/libro de Alan Kay donde hable sobre OOP y sus definiciones.

Hoy en día, si alguien quiere aprender sobre teoría de objetos (no en el sentido práctico de Stepanov, sino en el sentido OOP), yo le recomendaría leer a Bertrand Meyer.


http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_1?s=books&ie=UTF8&qid=1401974729&sr=1-1&keywords=object+oriented+software+construction


Saludos,Fernando.


Ahhh, y una cosa que detesto es la palabra "método", que alguien por favor me apunte a su definición (CS).
Muerte a quien popularizó el término ;) Quién fue? Fowler? juaaaaUsemos función, procedimiento, rutina..... 

_______________________________________________
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/20140605/fc66c8e4/attachment-0001.html>