Opinion sobre los array en Python

[Antonio Castro]

On Mon, 19 Apr 2004, Hernan Foffani wrote:

> [...]

> El problema es que *todos* los tipos de datos de python son *objetos*
> por lo que NO es posible optimizar
>     mi_array[4] = 3

Pero eso problema ya está resuelto en el módulo array de python.
Lo que se hace es informar del tipo de array que se quiere construir
indicandolo con un caracter. La clave es saber que cada elemento
ocupa exatamente el mismo tamaño por ser del mismo tipo.

> a un par de instrucciones de ensamblador como lo haría un buen
> compilador de C.
> Como máximo python podría obtener la *referencia* al objeto en pocas
> instrucciones de ensamblado (y nunca sería lo mismo que C ya que
> python tiene que controlar los desbordes en tiempo real) pero
> todavía resta el procesamiento de cada elemento del vector.
>
> El '3' de la asignacion anterior es un objeto como cualquier otro.

Ya lo se pero eso no significa que la implementación de un array
tenga que hacerse como una implementación de array para objetos
en general.

> Si se quiere igualar la velocidad de C en bucles como el ejemplo
> que has mencionado no basta con un tipo de datos array como el que
> propones.  Que los elementos sean todos enteros o todos tuplas
> o una mezcla heterogenea de objetos es irrelevante para el *array*
> en sí mismo.
>
> El problema de python se "reduce" a tener que transformar el '3'
> de objeto int (que en python tiene propiedades especiales como el
> hecho que el valor maximo de un entero está acotado *solo* por la
> memoria disponible en tu ordenador) a los 16 o 32 bits de internos
> del procesador.
>
> En otras palabras, la enorme dificultad de optimizar
>    mi_array[4] = 3
> no está en la implementacion de 'mi_array' sino en el '3' (y
> también en el '4')

El indice de un array ha de ser un entero positivo. La sintaxis en el
manejo de los elementos de una lista presentaría el mismo tipo de
problemas que el manejo de arrays.

> En resumen:
> Cambiar PyList_New(int size) a algo como PyListFloat_New(size)
> que haga 'nbytes = size * sizeof(float);' es el menor de
> los problemas.
> La dificultar reside es predecir el tiempo de vida (en flujo de
> programa no en segundos) de los objetos sobre todo de aquellos se
> podrían implementar como nativos.
>
> Dicho de otra forma. Disponer de una estantería especialmente
> diseñada para alojar con eficacia hojas A4 es inutil si
> no puedo saber de antemano que las 'cosas' que tengo que
> guardar y recuperar son folios de este tipo.
>
> Hay alternativas en estudio *dentro* del lenguaje.  Un proyecto
> interesante es Psyco.  Es un 'specialized compiler' (no se si la
> traduccion literal es el nombre academico.)
> Otros están estudiando algoritmos de predicción de tipos mediante
> analisis de flujo de programa o mediante analisis en tiempo de
> ejecución.  Otra aproximación es un python con anotación de tipos.
> Por desgracia ninguna es trivial.
>
> Espero haberme explicado mejor.

Yo no veo el problema en nada de lo que dices.
Es cierto que python permite hacer cosas del tipo:

	a = 5
	print a
	a= 'cinco'
	print a

A en cada instante 'a' es un objeto distinto con un tamaño perfectamente
delimitado. Por ello no es un problema para una implementación de arrays
optimizados para elementos de tamaño constante. Ya está hecho como
módulo array. Implementarlo en el lenguaje tambien se puede hacer dado que
el tamaño de los elementos es conocido.

Existe un módulo copy para copiar objetos y existe la copia profunda
y la copya superficial. Me queda claro que para copiar un objeto hace
falta conocer su tamaño. Por ello la copia de la variable 'a' funcionará
de forma distinta si 'a' contiene un objeto o contiene otro. El interprete
tiene que saber en todo momento el tamaño de los objetos que está
manejando y la direccion de memoria donde están alojados. No hace falta
saber nada más para implementar un array.

Yo sigo pensando que la implementacion de array en el propio lenguaje es
posible y deseable. Es cierto que he subestimado la importancia del coste
de funcionamiento de python como interprete que es muy alto, pero ese es
un precio que tiene sentido pagar. Creo que aunque existan partes importantes
que no se pueden optimizar hay otras muchas que si. La discusión se centra
en si los arrays se pueden optimizar implementandolos en el propio
lenguaje.

A la vista del alto coste que supone una simple llamada a función a mi me
parece que tiene incluso más sentido intentar implementarlo dentro del
lenguaje precisamente para evitar ese coste,  pero claro cada uno
exponemos argumentos que por el momento no pueden ser ni demostrados
ni rebatidos.


-- 
Un saludo
Antonio Castro

       /\     /\
         \\W//
        _|0 0|_
+-oOOO-(___o___)-OOOo---------------------+
| . . . . U U . Antonio Castro Snurmacher |
| . . . . . . . acastro en ciberdroide.com   |
+()()()---------()()()--------------------+