tuple python español

¿Por qué necesitamos tuplas en Python(o cualquier tipo de datos inmutables)? (9)

He leído varios tutoriales de Python (Dive Into Python, por ejemplo), y la referencia del lenguaje en Python.org - No veo por qué el lenguaje necesita tuplas.

Las tuplas no tienen métodos en comparación con una lista o conjunto, y si debo convertir una tupla a un conjunto o lista para poder ordenarlos, ¿de qué sirve usar una tupla en primer lugar?

¿Inmutabilidad?

¿Por qué a alguien le importa si una variable vive en un lugar diferente en la memoria que cuando se asignó originalmente? Todo este asunto de la inmutabilidad en Python parece estar muy enfatizado.

En C / C ++ si asigno un puntero y apunto a alguna memoria válida, no me importa dónde está ubicada la dirección, siempre que no sea nula antes de usarla.

Cada vez que hago referencia a esa variable, no necesito saber si el puntero sigue apuntando a la dirección original o no. Solo compruebo null y lo uso (o no).

En Python, cuando asigno una cadena (o tupla), asígnelo a x, luego modifique la cadena, ¿por qué me importa si es el objeto original? Siempre que la variable apunte a mis datos, eso es todo lo que importa.

>>> x=''hello'' >>> id(x) 1234567 >>> x=''good bye'' >>> id(x) 5432167

x todavía hace referencia a los datos que quiero, ¿por qué alguien necesita importar si su identificación es la misma o diferente?

si debo convertir una tupla a un conjunto o lista para poder ordenarlos, ¿de qué sirve usar una tupla en primer lugar?

En este caso particular, probablemente no haya un punto. Esto no es un problema, porque este no es uno de los casos en los que consideraría usar una tupla.

Como usted señala, las tuplas son inmutables. Las razones para tener tipos inmutables se aplican a tuplas:

eficacia de copia: en lugar de copiar un objeto inmutable, puede alias (vincular una variable a una referencia)
Eficiencia de comparación: cuando usa copia por referencia, puede comparar dos variables comparando la ubicación, en lugar del contenido
interno: necesitas almacenar como máximo una copia de cualquier valor inmutable
no es necesario sincronizar el acceso a objetos inmutables en código concurrente
const correctness: no se debe permitir que cambien algunos valores. Esto (para mí) es la razón principal de los tipos inmutables.

Tenga en cuenta que una implementación particular de Python puede no hacer uso de todas las características anteriores.

Las claves de diccionario deben ser inmutables, de lo contrario, el cambio de las propiedades de un objeto clave puede invalidar las invariantes de la estructura de datos subyacente. Las tuplas se pueden usar potencialmente como claves. Esto es una consecuencia de la corrección const.

Véase también " Introducción de tuplas ", de Dive Into Python .

los objetos inmutables pueden permitir una optimización sustancial; esto es presumiblemente por qué las cadenas también son inmutables en Java, desarrolladas por separado, pero al mismo tiempo que Python, y casi todo es inmutable en lenguajes verdaderamente funcionales.
en Python en particular, solo los inmutables pueden ser hashable (y, por lo tanto, miembros de conjuntos o claves en diccionarios). Nuevamente, esto permite la optimización, pero mucho más que solo "sustancial" (diseñar tablas de hash decentes que almacenen objetos completamente mutables es una pesadilla; o bien se toman copias de todo tan pronto como se tiene, o la pesadilla de comprobar si el hash del objeto ha cambiado desde la última vez que tomó una referencia, levanta su fea cabeza).

Ejemplo de problema de optimización:

$ python -mtimeit ''["fee", "fie", "fo", "fum"]'' 1000000 loops, best of 3: 0.432 usec per loop $ python -mtimeit ''("fee", "fie", "fo", "fum")'' 10000000 loops, best of 3: 0.0563 usec per loop

A veces nos gusta usar objetos como claves del diccionario

Por lo que vale, las tuplas recientemente (2.6+) crecieron métodos index() y count()

Como gnibbler ofreció en un comentario, Guido tuvo una aspn.activestate.com/ASPN/Mail/Message/python-list/1566320 que no es totalmente aceptada / apreciada: "las listas son para datos homogéneos, las tuplas son para datos heterogéneos". Por supuesto, muchos de los opositores interpretaron esto como lo que significa que todos los elementos de una lista deben ser del mismo tipo.

Me gusta verlo de manera diferente, a diferencia de others también lo han hecho en el pasado:

blue= 0, 0, 255 alist= ["red", "green", blue]

Tenga en cuenta que considero que alist es homogéneo, incluso si type (alist [1])! = Type (alist [2]).

Si puedo cambiar el orden de los elementos y no tendré problemas en mi código (aparte de las suposiciones, por ejemplo, "debería ser ordenado"), se debe usar una lista. Si no (como en el blue la tupla anterior), entonces debería usar una tupla.

Ninguna de las respuestas anteriores señala el verdadero problema de las listas de tuplas vs, que muchas de las nuevas de Python parecen no entender del todo.

Tuplas y listas tienen diferentes propósitos. Las listas almacenan datos homogéneos. Puede y debe tener una lista como esta:

["Bob", "Joe", "John", "Sam"]

La razón por la cual es un uso correcto de las listas es porque esos son todos tipos de datos homogéneos, específicamente, los nombres de las personas. Pero toma una lista como esta:

["Billy", "Bob", "Joe", 42]

Esa lista es el nombre completo de una persona y su edad. Ese no es un tipo de datos. La forma correcta de almacenar esa información es en una tupla o en un objeto. Digamos que tenemos algunos:

[("Billy", "Bob", "Joe", 42), ("Robert", "", "Smith", 31)]

La inmutabilidad y mutabilidad de Tuplas y Listas no es la principal diferencia. Una lista es una lista del mismo tipo de elementos: archivos, nombres, objetos. Las tuplas son una agrupación de diferentes tipos de objetos. Tienen diferentes usos, y muchos codificadores de Python hacen uso indebido de listas de para qué tuplas están destinadas.

Por favor no.

Editar:

Creo que esta publicación de blog explica por qué creo que esto es mejor que lo que hice: http://news.e-scribe.com/397

Siempre he encontrado que tener dos tipos completamente separados para la misma estructura de datos básica (matrices) es un diseño incómodo, pero no es un problema real en la práctica. (Todos los lenguajes tienen sus verrugas, Python incluido, pero esto no es importante).

¿Por qué a alguien le importa si una variable vive en un lugar diferente en la memoria que cuando se asignó originalmente? Todo este asunto de la inmutabilidad en Python parece estar muy enfatizado.

Estas son cosas diferentes. La mutabilidad no está relacionada con el lugar donde está almacenada en la memoria; significa que las cosas que señala no pueden cambiar.

Los objetos de Python no pueden cambiar de ubicación después de haber sido creados, mutables o no. (Más exactamente, el valor de id () no puede cambiar, lo mismo, en la práctica). El almacenamiento interno de objetos mutables puede cambiar, pero ese es un detalle de implementación oculto.

>>> x=''hello'' >>> id(x) 1234567 >>> x=''good bye'' >>> id(x) 5432167

Esto no modifica ("mutando") la variable; está creando una nueva variable con el mismo nombre y descartando la anterior. Compare con una operación de mutación:

>>> a = [1,2,3] >>> id(a) 3084599212L >>> a[1] = 5 >>> a [1, 5, 3] >>> id(a) 3084599212L

Como han señalado otros, esto permite usar matrices como claves para diccionarios y otras estructuras de datos que necesitan inmutabilidad.

Tenga en cuenta que las claves para los diccionarios no tienen que ser completamente inmutables. Solo la parte de ella utilizada como clave debe ser inmutable; para algunos usos, esta es una distinción importante. Por ejemplo, podría tener una clase que represente a un usuario, que compare la igualdad y un hash con el nombre de usuario único. Luego puede colgar otros datos mutables en la clase - "el usuario ha iniciado sesión", etc. Como esto no afecta la igualdad o el hash, es posible y perfectamente válido usar esto como una clave en un diccionario. Esto no es muy comúnmente necesario en Python; Simplemente lo señalo porque varias personas han afirmado que las claves deben ser "inmutables", lo cual es parcialmente correcto. Sin embargo, he usado esto muchas veces con mapas y conjuntos C ++.

Son importantes ya que garantizan que quien llama no cambiará de objeto. Si haces esto:

a = [1,1,1] doWork(a)

La persona que llama no tiene garantía del valor de a después de la llamada. Sin embargo,

a = (1,1,1) doWorK(a)

Ahora usted, como persona que llama o como lector de este código, sabe que a es lo mismo. En este caso, siempre podría hacer una copia de la lista y pasarla, pero ahora está desperdiciando ciclos en lugar de usar una construcción de lenguaje que tenga más sentido semántico.

Su pregunta (y los comentarios de seguimiento) se centran en si el id () cambia durante una tarea. Centrarse en este efecto de continuación de la diferencia entre la sustitución de objetos inmutables y la modificación de objetos mutables en lugar de la diferencia en sí misma quizás no sea el mejor enfoque.

Antes de continuar, asegúrese de que el comportamiento que se muestra a continuación es el que espera de Python.

>>> a1 = [1] >>> a2 = a1 >>> print a2[0] 1 >>> a1[0] = 2 >>> print a2[0] 2

En este caso, el contenido de a2 se modificó, aunque solo a1 tenía un nuevo valor asignado. Contraste a lo siguiente:

>>> a1 = [1] >>> a2 = a1 >>> print a2[0] 1 >>> a1 = [2] >>> print a2[0] 1

En este último caso, reemplazamos toda la lista, en lugar de actualizar sus contenidos. Con tipos inmutables como tuplas, este es el único comportamiento permitido.

¿Por qué importa esto? Digamos que tienes un dict:

>>> t1 = (1,2) >>> d1 = { t1 : ''three'' } >>> print d1 {(1,2): ''three''} >>> t1[0] = 0 ## results in a TypeError, as tuples cannot be modified >>> t1 = (2,3) ## creates a new tuple, does not modify the old one >>> print d1 ## as seen here, the dict is still intact {(1,2): ''three''}

Usando una tupla, el diccionario está a salvo de tener sus claves cambiadas "fuera de debajo" a elementos que tienen un valor diferente. Esto es crítico para permitir una implementación eficiente.

usted puede ver here para un debate sobre este