select case

[Rafael Villar Burke]

Pepe Aracil wrote:

>Lo del "is" no lo tengo tan claro. Por alguna razón de optimización , funciona 
>con enteros del 0 a 99, lo que puede resultar algo confuso y podría cambiar 
>en futuras versiones o implementaciones de python.
>  
>
Cierto, hablé demasiado a la ligera :)... los números en general no son 
el caso más afortunado. Seguramente que por cuestiones de optimización 
no se mantienen como verdaderos objetos en memoria, salvo en un rango 
pequeño (el más útil). En un caso ideal todos serían objetos singulares 
(singleton). Si nos volvemos locos con la velocidad también merece la 
pena ver esto: 
http://mail.python.org/pipermail/python-dev/2002-January/019113.html

Otros consejos que me gustaron, y que tratan sobre expresiones como:
if x == 0, if x == "", if x == None, if x == False, etc...
es http://jaynes.colorado.edu/PythonIdioms.html

De todos modos, para los casos en los que tenemos ese tipo de objetos 
únicos (objetos de estado, None, True o False, etc), es más rápida una 
comparación de referencias de memoria que una comprobación de igualdad, 
y la sintaxis de 'is' creo que recalca más la identidad. En el PEP-8 se 
habla en algunos párrafos de estas cosas.

También pensaba que en C el uso de enteros se hace con un valor 
semántico que no necesariamente debe trasladarse a python. En C es 
frecuente crear enumeraciones y operar luego con sus símbolos como 
enteros. De la misma manera muchas constantes se implementan como 
enteros únicos, etc. Es, por ello, normal que cuando se ha visto eso mil 
veces se repita en python, cuando en éste a menudo la implementación se 
hará a través de objetos y no enteros (pensados como no objetos). Por 
ejemplo, si se hace una asignación múltiple a un conjunto de nombres 
desde un rango se puede usar cada nombre como una instancia de la clase 
int y usar esos nombres de la manera que explicaba para el select, con 
'is'. En el caso de None esto ya parece natural, pero se puede extender 
a los objetos que creemos en nuestros programas.

Así, con select, es frecuente que la comparación sea con valores 
inmutables, que, si se usan en diferentes puntos del código, sería 
recomendable que apareciesen a traves de un nombre y no de su valor. 
Esto permite modificar su valor en el futuro actuando en un solo punto; 
recalcar que no se trata meramente de coincidencia de valor, sino de un 
mismo contenido semántico, etc.

Bueno, esto es lo que he ido pensando sobre el asunto. Si se busca en 
google por "python identity equality" hay unas 16500 entradas y muchas 
muy interesantes.
Me gusta cuando la gente de la lista cuenta lo que ha ido experimentando 
y pensando a raíz de su trabajo con python. :).

Saludos,

Pachi
------------ próxima parte ------------
_______________________________________________
Python-es mailing list
Python-es en aditel.org
http://listas.aditel.org/listinfo/python-es