python - trabajar - ¿Por qué las cadenas de pitón y las tuplas se vuelven inmutables?
tutorial ipython español (6)
No estoy seguro de por qué las cuerdas y las tuplas fueron hechas para ser inmutables; ¿Cuáles son las ventajas y desventajas de hacerlos inmutables?
Una es el rendimiento: saber que una cuerda es inmutable hace que sea fácil de diseñar en el momento de la construcción, requisitos de almacenamiento fijos e invariables. Esta es también una de las razones para la distinción entre tuplas y listas. Esto también permite que la implementación reutilice de forma segura los objetos de cadena. Por ejemplo, la implementación de CPython usa objetos preasignados para cadenas de caracteres individuales, y generalmente devuelve la cadena original para operaciones de cadenas que no cambia el contenido.
La otra es que las cadenas en Python se consideran como "elementales" como números. Ninguna cantidad de actividad cambiará el valor 8 por otra cosa, y en Python, ninguna cantidad de actividad cambiará la cadena "ocho" a ninguna otra cosa.
http://effbot.org/pyfaq/why-are-python-strings-immutable.htm
Imagina un lenguaje llamado FakeMutablePython, donde puedes modificar cadenas usando la asignación de listas y mystr[0] = ''a'' por el mystr[0] = ''a'' (como mystr[0] = ''a'' )
a = "abc"
Eso crea una entrada en la memoria en la dirección de memoria 0x1, que contiene "abc", y el identificador a apuntando a ella.
Ahora, di que lo haces ..
b = a
Esto crea el identificador b y también lo apunta a la misma dirección de memoria de 0x1
Ahora, si la cadena fue mutable, y cambias b :
b[0] = ''z''
Esto altera el primer byte de la cadena almacenada en 0x1 a z .. Dado que el identificador a apunta hacia aquí, por lo tanto esa cadena también se alteraría, así que ...
print a
print b
..would ambos salida zbc
Esto podría generar un comportamiento realmente extraño e inesperado. Las claves del diccionario serían un buen ejemplo de esto:
mykey = ''abc''
mydict = {
mykey: 123,
''zbc'': 321
}
anotherstring = mykey
anotherstring[0] = ''z''
Ahora, en FakeMutablePython, las cosas se vuelven bastante raras: inicialmente tienes dos teclas en el diccionario, "abc" y "zbc". Luego modificas la cadena "abc" (a través del identificador anotherstring ) a "zbc", por lo que el dict ha dos teclas, "zbc" y "zbc" ...
Una solución a esta rareza sería que cada vez que asigne una cadena a un identificador (o la use como una clave dict), copie la cadena de 0x1 a 0x2.
Esto evita lo anterior, pero ¿qué sucede si tiene una cadena que requiere 200 MB de memoria?
a = "really, really long string [...]"
b = a
De repente, su secuencia de comandos ocupa 400 MB de memoria? Esto no es muy bueno
¿Y si apuntamos a la misma dirección de memoria, hasta que la modifiquemos? Copia en escritura . El problema es que esto puede ser bastante complicado de hacer ...
Aquí es donde entra la inmutabilidad. En lugar de requerir que el método .replace() copie la cadena de la memoria en una nueva dirección, .replace() y devuélvala. Simplemente hacemos que todas las cadenas sean inmutables, y así la función debe crear una nueva cuerda para regresar. Esto explica el siguiente código:
a = "abc"
b = a.replace("a", "z")
Y está probado por:
>>> a = ''abc''
>>> b = a
>>> id(a) == id(b)
True
>>> b = b.replace("a", "z")
>>> id(a) == id(b)
False
(la función id() devuelve la dirección de memoria del objeto)
Los tipos inmutables son conceptualmente mucho más simples que los mutables. Por ejemplo, no tiene que meterse con los constructores de copia o const-correctness como en C ++. Cuantos más tipos sean inmutables, más fácil será el idioma. Por lo tanto, los lenguajes más fáciles son los funcionales puros sin ningún estado global (porque el cálculo lambda es mucho más fácil que las máquinas de Turing, e igualmente poderoso), aunque mucha gente no parece apreciar esto.
Perl tiene cadenas mutables y parece funcionar bien. Lo anterior parece mucho movimiento de manos y racionalización para una decisión de diseño arbitraria.
Mi respuesta a la pregunta de por qué Python tiene cuerdas inmutables, porque el creador de Python, Guido van Rossum, lo quería así y ahora tiene legiones de admiradores que defenderán esa decisión arbitraria hasta su último aliento.
Podrías plantearte una pregunta similar sobre por qué Perl no tiene cuerdas inmutables y un grupo entero de personas escribiría cuán horrible es el concepto mismo de cadenas inmutables y por qué es la idea más inolvidable (TM) de que Perl no las tenga. .
Una gran ventaja de hacerlos inmutables es que pueden usarse como claves en un diccionario. Estoy seguro de que las estructuras internas de datos utilizadas por los diccionarios se desordenarían bastante si se permitiera que las claves cambiaran.
pros: rendimiento
contras: no puede cambiar las tablas mutables.