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

He leído varios tutoriales de Python (Sumérgete en 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 comparados con una lista o conjunto, y si debo convertir una tupla en un conjunto o lista para poder ordenarlos, ¿cuál es el punto de 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 negocio de inmutabilidad en Python parece estar demasiado enfatizado.

En C / C ++ si asigno un puntero y apunto a alguna memoria válida, no me importa dónde se encuentra 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 busco nulo y lo uso (o no).

En Python, cuando asigno una cadena (o tupla), la asigno a x, luego modifico la cadena, ¿por qué me importa si es el objeto original? Mientras 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 debe preocuparse si su identificación es la misma o diferente?

1. los objetos inmutables pueden permitir una optimización sustancial; presumiblemente, esta es la razón por la cual las cadenas también son inmutables en Java, desarrolladas por separado pero casi al mismo tiempo que Python, y casi todo es inmutable en lenguajes verdaderamente funcionales.

2. en Python en particular, solo los inmutables pueden ser hashables (y, por lo tanto, miembros de conjuntos o claves en los diccionarios). Nuevamente, esto permite la optimización, pero es mucho más que simplemente "sustancial" (diseñar tablas hash decentes que almacenen objetos completamente mutables es una pesadilla, ya sea que tomes copias de todo tan pronto como lo hagas, o la pesadilla de verificar si el hash del objeto ha cambiado desde la última vez que hizo referencia a que 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

Ninguna de las respuestas anteriores señala el problema real de las tuplas frente a las listas, que muchos nuevos en Python parecen no comprender completamente.

Las tuplas y las 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 la mutabilidad de las tuplas y las 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 abusan de las listas para lo que están destinadas las tuplas.

Por favor no

Editar:

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

si debo convertir una tupla en un conjunto o lista para poder ordenarlos, ¿cuál es el punto de 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 señalas, las tuplas son inmutables. Las razones para tener tipos inmutables se aplican a las tuplas:

• eficiencia de copia: en lugar de copiar un objeto inmutable, puede usar un alias (vincular una variable a una referencia)
• eficiencia de comparación: cuando utiliza la copia por referencia, puede comparar dos variables comparando la ubicación, en lugar del contenido
• Interno: necesita almacenar como máximo una copia de cualquier valor inmutable
• no hay necesidad de sincronizar el acceso a objetos inmutables en código concurrente
• corrección const: algunos valores no deberían poder cambiar. 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 del diccionario deben ser inmutables; de lo contrario, cambiar las propiedades de un objeto clave puede invalidar invariantes de la estructura de datos subyacente. Las tuplas se pueden usar como claves. Esto es una consecuencia de la corrección constante.

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

A veces nos gusta usar objetos como teclas de diccionario

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

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 un problema real en la práctica. (Cada idioma tiene sus verrugas, Python incluido, pero este 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 negocio de inmutabilidad en Python parece estar demasiado enfatizado.

Estas son cosas diferentes. La mutabilidad no está relacionada con el lugar donde se almacena 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 que se crean, 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 está modificando ("mutando") la variable; está creando una nueva variable con el mismo nombre y descartando la anterior. Compárese con una operación mutante:

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

Como otros han señalado, 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 que se usa 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 compara la igualdad y un hash por el nombre de usuario único. Luego podría colgar otros datos mutables en la clase: "el usuario ha iniciado sesión", etc. Dado que esto no afecta la igualdad o el hash, es posible y perfectamente válido usar esto como clave en un diccionario. Esto no se necesita con demasiada frecuencia en Python; Solo lo señalo, ya que varias personas han afirmado que las claves deben ser "inmutables", lo cual es solo parcialmente correcto. Sin embargo, he usado esto muchas veces con mapas y conjuntos de C ++.

Como gnibbler ofreció en un comentario, Guido tenía una opinión 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 que esto significa que todos los elementos de una lista deberían ser del mismo tipo.

Me gusta verlo de manera diferente, no muy diferente de lo que otros han tenido 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 los supuestos, por ejemplo, "debería estar ordenado"), entonces debería usarse una lista. Si no (como en la tupla blueanterior), entonces debería usar una tupla.

Son importantes ya que garantizan a la persona que llama que el objeto que pasa no será mutado. Si haces esto:

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

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

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

Ahora, como llamante o como lector de este código, sabe que a es lo mismo. Para este escenario, 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.

puedes ver aquí para una discusión sobre esto

Su pregunta (y comentarios de seguimiento) se centran en si el id () cambia durante una tarea. Centrarse en este efecto de continuación de la diferencia entre el reemplazo 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 sea el que espera de Python.

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

En este caso, se cambió el contenido de a2, 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 la lista completa, en lugar de actualizar su contenido. Con tipos inmutables como las 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 que sus claves se cambien "por debajo de él" a elementos que se combinan con un valor diferente. Esto es crítico para permitir una implementación eficiente.