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

[Leandro E. Colombo Viña]

Vamos a tomar cerveza?
El 05/06/2014 14:04, "Luis Masuelli" <luismasuelli en hotmail.com> escribió:

> Para mi es una desventaja pero tampoco me es tan importante. No tuve un
> caso de uso en el que haya tenido que distinguir entre __get y __call. Mi
> planteo (entonces y ahora) fue mas teorico que otra cosa.
>
> Si quiero ponerme en puto lo que se me ocurre es obtener el atributo y
> distinguir si es un types.UnboundMethodType con la instancia puesta == self
> (no, no siempre se me ocurrio eso xD).
>
>
>
> > Date: Thu, 5 Jun 2014 12:34:18 -0300
> > From: klaussfreire en gmail.com
> > To: pyar en python.org.ar
> > Subject: Re: [pyar] [video] En Python tenemos nombres, no variables.
> >
> > 2014-06-05 12:30 GMT-03:00 Claudio Freire <klaussfreire en gmail.com>:
> > > 2014-06-05 12:14 GMT-03:00 Luis Masuelli <luismasuelli en hotmail.com>:
> > >> 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.
> > >
> > >
> > > La diferencia radica en que el acceso a atributos es una operación en
> > > sí en el lenguaje Python, y la llamada es otra.
> > >
> > > La expresión
> > >
> > > x.hacer(y)
> > >
> > > En realidad tiene dos operaciones: obtener el atributo "hacer" de x, y
> > > llamarlo con parámetro y.
> > >
> > > No existe __call porque ese atributo hacer no tiene nada de especial.
> > > Hasta se puede asignar. Así que la forma de manejarlo, es exactamente
> > > lo que hiciste. Y la forma de hacerlo convivir con atributos
> > > existentes, es llamando a super() y atrapando la excepción que resulta
> > > de acceder algo no definido (aunque hay que tener cuidado acá con la
> > > recursión, getattr vs getattribute, etc).
> > >
> > > En síntesis, uno podría decir que los métodos no son parte del
> > > lenguaje. Python tiene clases y atributos, nada más. Los métodos son
> > > atributos que oh casualidad son llamables.
> >
> > Perdón, se me chispoteó el send antes del punchline:
> >
> > Esto es una fortaleza importante de Python, del mismo tipo que la
> > habilidad de Smalltalk y Lisp: menos semántica fija = más flexibilidad
> > = más potencial de metaprogramación.
> >
> > Puede que te lleve más líneas escribir lo que hacías con __call en
> > php, pero eso es bueno, porque también te permite hacer más.
> > _______________________________________________
> > 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/20140605/916a6a47/attachment.html>