[Python-es] why builtin functions?

[Chema Cortes]

El 6 de agosto de 2014, 1:59, Daπid <davidmenhur en gmail.com> escribió:

> On 6 August 2014 00:43, Jose Caballero <jcaballero.hep en gmail.com> wrote:
>
>> En particular, mi colega me pregunta que por que python  implementa la
>> funcion  len( )   pero no existe el metodo len() para clases como
>> list, string, etc.
>>
>
> Sí existe, pero se llama __len__(). La existencia de algunos builtins está
> clara: son propiedades muy básicas útiles para muchos objetos diferentes.
> Si simplemente existiera el método .len(), un programador perezoso podría
> llamar al método correspodiente .size() o .shape() (e.g.: arrays de Numpy),
> y trabajar con secuencias sería mucho más difícil. ¿Cómo de larga es?
> ¿Tiene el método len()?
>
> Al fijar un método mágico y un builtin como alias, Python enfuerza una API
> concreta para cualquier tipo de secuencias.
>
> Funciones como max() o min() son operaciones muy comunes, que se
> benefician enormemente de estar programadas en C. De nuevo, las secuencias
> en la biblioteca estandard podrían haber implementado .max() en C, pero
> entonces tendríamos que volver a reimplementarlo para cada nuevo clase que
> creáramos (y la API C es dura).
>

Te olvidas que estamos trabajando en un lenguaje orientado a objetos que,
además, admite herencia múltiple con la que hacer mixins. Para que una
clase pudiera ordenarse, bastaría con hacer que derivara de una superclase
(eg: Ordered) que fuera la que tuviera implementado en C las operaciones de
max y min.

Si ahora te funciona max y min es porque te apoyas en algún tipo de dato
ordenable (int, float, string, etc) o porque puedes pasar como argumento
una función (key) que asocia un tipo ordenable a cada elemento de tu lista
o un argumento que realiza la relación de orden (cmp).

Bien podía residir toda esta lógica en superclases e, incluso, diría que es
lo deseable y hacia donde va python ahora mismo con las clases abstractas.
Tener los builtins es por comodidad y como modo de empezar un diálogo con
el intérprete para conocer el entorno donde reside tu aplicación, lo que se
llama "instrospección" y de lo que trataba el tema de la referencia inicial.


>
> El caso de type() es que el intérprete de Python sabe mejor qué es
> cualquier objeto que ellos mismos. Podría haberse implementado como un
> método añadido automáticamente a cualquier objeto, pero sería añadir magia
> negra porque:
>
> class Nothing():
>    pass
>
> tendría métodos definidos, y podría ser sobreescrito:
>
> class Pranker(object):
>     def type(self):
>          import antrigravity
>          return None
>
> Está claro que debería ser de sólo lectura, pero lo haría un caso especial.
>
>
> /David.
>
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> https://mail.python.org/mailman/listinfo/python-es
> FAQ: http://python-es-faq.wikidot.com/
>
>


-- 
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/20140806/a1a38052/attachment.html>