<!-- Generated using "markdown-toc -i README.md --maxdepth 3"-->

<!-- toc -->

- [Estructura de los ejemplos](#estructura-de-los-ejemplos)

+ [▶ Título](#-título)

- [Uso](#Uso)

- [👀 Ejemplos](#-ejemplos)

* [Sección: ¡ejercita tu cerebro!](#sección-ejercita-tu-cerebro)

+ [▶ ¡Primero lo primero! *](#-primero-lo-primero-)

+ [▶ Los strings pueden ser confusos de vez en cuando](#-los-strings-pueden-ser-confusos-de-vez-en-cuando)

+ [▶ Ten cuidado con las operaciones en cadena](#-ten-cuidado-con-las-operaciones-en-cadena)

+ [▶ Como no utilizar el operador `is`](#-como-no-utilizar-el-operador-is)

+ [▶ Dulces hash](#-dulces-hash)

+ [▶ En el fondo, todos somos iguales](#-en-el-fondo-todos-somos-iguales)

+ [▶ Desorden en el orden *](#-desorden-en-el-orden-)

+ [▶ Sigue intentando... *](#-sigue-intentando-)

+ [▶ ¿Para qué?](#-para-qué)

+ [▶ Discrepancia de evaluación de tiempo](#-discrepancia-de-evaluación-de-tiempo)

+ [▶ `is not ...` no es `is (not ...)`](#-is-not--no-es-is-not-)

+ [▶ ¡Un tres en raya en donde la X gana la primera jugada!](#-un-tres-en-raya-en-donde-la-x-gana-la-primera-jugada)

+ [▶ La variable de Schrödinger *](#-la-variable-de-schrödinger-)

+ [▶ El problema del huevo de gallina *](#-el-problema-del-huevo-de-gallina-)

+ [▶ Relaciones entre subclases](#-relaciones-entre-subclases)

+ [▶ Equidad e identidad de métodos](#-equidad-e-identidad-de-métodos)

+ [▶ Siempre verdadero *](#-siempre-verdadero-)

+ [▶ La coma extraña](#-la-coma-extraña)

+ [▶ Strings y barras invertidas](#-strings-y-barras-invertidas)

+ [▶ ¡Ahora no!](#-ahora-no)

+ [▶ Strings con medias tres comillas](#-strings-con-medias-tres-comillas)

+ [▶ ¿Cuál es el problema con los booleanos?](#-cuál-es-el-problema-con-los-booleanos)

+ [▶ Atributos de clase y de instancia](#-atributos-de-clase-y-de-instancia)

+ [▶ Devolviendo `None`](#-devolviendo-none)

+ [▶ ¡Usando `yield` desde return! *](#-usando-yield-desde-return-)

+ [▶ Reflexividad NAN *](#-reflexividad-nan-)

+ [▶ ¡Mutando lo inmutable!](#-mutando-lo-inmutable)

+ [▶ La variable de alcance exterior que desaparece](#-la-variable-de-alcance-exterior-que-desaparece)

+ [▶ La misteriosa conversión de la llave](#-la-misteriosa-conversión-de-la-llave)

+ [▶ Veamos si puedes adivinar esto...](#-veamos-si-puedes-adivinar-esto)

* [Sección: pendientes resbaladizas](#sección-pendientes-resbaladizas)

+ [▶ Modificando un diccionario a la vez que iteramos por él](#-modificando-un-diccionario-a-la-vez-que-iteramos-por-él)

+ [▶ El rebelde operador `del`](#-el-rebelde-operador-del)

+ [▶ La variable fuera de alcance](#-la-variable-fuera-de-alcance)

+ [▶ Borrar un elemento de una lista al iterar sobre ella](#-borrar-un-elemento-de-una-lista-al-iterar-sobre-ella)

+ [▶ Pérdidas en los iteradores *](#-pérdidas-en-los-iteradores-)

+ [▶ ¡Fuga de variables en bucles!](#-fuga-de-variables-en-bucles)

+ [▶ ¡Ten cuidado con los argumentos mutables predeterminados!](#-ten-cuidado-con-los-argumentos-mutables-predeterminados)

+ [▶ Detectando las excepciones](#-detectando-las-excepciones)

+ [▶ ¡Mismos operandos, cuestiones diferentes!](#-mismos-operandos-cuestiones-diferentes)

+ [▶ Resolución de nombres ignorando el alcance de la clase](#-resolución-de-nombres-ignorando-el-alcance-de-la-clase)

+ [▶ Agujas en un pajar *](#-agujas-en-un-pajar-)

+ [▶ Separando valores *](#-separando-valores-)

+ [▶ Importes "wild" *](#-importes-wild-)

+ [▶ ¿Todo ordenado? *](#-todo-ordenado-)

+ [▶ ¿No existe la medianoche?](#-no-existe-la-medianoche)

* [Sección: ¡tesoros ocultos!](#sección-tesoros-ocultos)

+ [▶ Python, ¿puedes hacerme volar?](#-python-puedes-hacerme-volar)

+ [▶ `goto`, pero, ¿por qué?](#-goto-pero-por-qué)

+ [▶ ¡Prepárate!](#-prepárate)

+ [▶ Conozcamos a Lenguage Amistoso, tío de por vida](#-conozcamos-a-lenguaje-amistoso-tío-de-por-vida)

+ [▶ Incluso Python sabe que el amor es complicado](#-incluso-python-sabe-que-el-amor-es-complicado)

+ [▶ ¡Si, existe!](#-si-existe)

+ [▶ Elipsis *](#-elipsis-)

+ [▶ "Inpinity"](#-inpinity)

+ [▶ Vamos a mangonear](#-vamos-a-mangonear)

* [Sección: ¡las apariencias engañan!](#sección-las-apariencias-engañan)

+ [▶ ¿Saltando líneas?](#-saltando-líneas)

+ [▶ Teletransportación](#-teletransportación)

+ [▶ Hm... algo es sospechoso...](#-hm-algo-es-sospechoso)

* [Sección: varios](#sección-varios)

+ [▶`+=` es más rápido](#--es-más-rápido)

+ [▶ ¡Hagamos un string super largo!](#-hagamos-un-string-super-largo)

+ [▶ Ralentizando revisiones de `dict` *](#-ralentizando-revisiones-de-dict-)

+ [▶ Instancias de `dict` *](#-instancias-de-dict-)

+ [▶ Cambios menores *](#-cambios-menores-)

- [Contribuir](#contribuir)

- [Reconocimientos](#reconocimientos)

- [🎓 Licencia](#-licencia)

* [¡Sorprende a tus amigos!](#sorprende-a-tus-amigos)

* [¿Necesitas una versión en PDF?](#necesitas-una-versión-en-pdf)

<!-- tocstop -->

Todos los ejemplos están estructurados de la siguiente manera:

> ### ▶ Título

> ```py

> # Comienzo del código.

> # Preparándose para la magia...

> ```

> **Output (version(es) de Python):**

> ```py

> >>> triggering_statement

> Output inesperado

> ```

> (Opcional): Una línea describiendo el output inesperado.

> #### 💡 Explicación:

> * Explicación corta de qué está ocurriendo y por qué está ocurriendo.

> ```py

> # Comienzo del código

> # Más ejemplos para entender mejor (si es necesario)

> ```

> **Output (version(es) de Python):**

> ```py

> >>> trigger # algún ejemplo que haga que sea fácil ver la magia

> # output justificado

> ```

**Nota:** Todos los ejemplos están probados en el intérprete interactivo en Python 3.5.2 y deberían funcionar en todas las otras versiones de Python a menos que se haya indicado explícitamente lo contrario en el output.

Una buena manera de obtener el mayor conocimiento de estos ejemplos, en mi opinión, es leerlos cronológicamente, y para cada ejemplo hacer lo siguiente:

- Leer el código inicial del comienzo del código cuidadosamente. Si eres un programador de Python experimentado seguramente anticiparás correctamente lo que pasará luego.

- Lee el output y,

+ Revisa si el output es igual al que te imaginabas.

+ Asegúrate de que conoces la razón exacta de que el output sea ese.

- Si la respuesta es "no" (lo cual está bien), toma un suspiro y lee la explicación de nuevo. Si aun no entiendes, ¡no te preocupes! puedes crear un Issue [aquí](https://github.com/JoseDeFreitas/wtfpython-es/issues/new).

- Si la respuesta es "si", puedes darte una palmadita en la espalda y leer el siguiente ejemplo.

PD: También puedes leer WTFPython en la línea de comandos usando el [paquete pypi](https://pypi.python.org/pypi/wtfpython),

```sh

$ pip install wtfpython -U

$ wtfpython

```

<!-- Example ID: d3d73936-3cf1-4632-b5ab-817981338863 -->

<!-- read-only -->

Por alguna razón, el operador "Walrus" de Python 3.8+ (`:=`) se ha vuelto popular. Vamos a verlo,

1\.

```py

>>> a = "wtf_walrus"

>>> a

>>> a := "wtf_walrus"

File "<stdin>", line 1

a := "wtf_walrus"

^

SyntaxError: invalid syntax

>>> (a := "wtf_walrus") # Esto sí funciona

>>> a

```

2 \.

```py

>>> a = 6, 9

>>> a

(6, 9)

>>> (a := 6, 9)

(6, 9)

>>> a

>>> a, b = 6, 9 # Desempaquetado común

>>> a, b

(6, 9)

>>> (a, b = 16, 19) # Oops

File "<stdin>", line 1

(a, b = 6, 9)

^

SyntaxError: invalid syntax

>>> (a, b := 16, 19) # Esto devuelve un tuple extraño de 3 elementos

(6, 16, 19)

>>> a # ¿permanece "a" sin cambios todavía?

>>> b

```

**Resumen rápido del operador Walrus**

El operador Walrus (`:=`) fue introducido en Python 3.8, y puede ser útil cuando quieras asignar valores a variables dentro de una expresión.

```py

def some_func():

# Asume una computación grande aquí

# time.sleep(1000)

return 5

if some_func():

print(some_func()) # Lo cual es una mala práctica porque la operación está ocurriendo dos veces

a = some_func()

if a:

print(a)

if a := some_func():

print(a)

```

**Output (> 3.8):**

```py

```

Esto nos salvó una línea de código e implícitamente previno la invocación de `some_func` dos veces.

- Una expresión de asignación sin parénteris (uso del operador Walrus) está restringida al nivel superior, por eso se devuelve el error `SyntaxError` en la declaración `a := "wtf_walrus"` en el primer código. Al poner paréntesis a la declaración hacemos que funcione correctamente y se asigne el valor a la variable `a`.

- Como siempre, al ponerle paréntesis a una expresión que contiene el operador `=` no está permitido. Es por eso que se devuelve el error en `(a, b = 6, 9)`.

- La sintaxis del operador Walrus está en la forma `NOMBRE := expresión`, donde `NOMBRE` es un identificador válido y `expresión` es una expresión válida. Por eso, el empaquetamiento y desempaquetamiento no está permitido, lo que significa que,

- `(a := 6, 9)` es equivalente a `((a := 6), 9)` y en consecuencia a `(a, 9)` (donde el valor de `a` es 6)

```py

>>> (a := 6, 9) == ((a := 6), 9)

True

>>> x = (a := 696, 9)

>>> x

(696, 9)

>>> x[0] is a # Ambos hacen referencia al mismo espacio en memoria

True

```

- Similarmente, `(a, b := 16, 19)` es equivalente a `(a, (b := 16), 19)` el cual no es más que un tuple de 3 elementos.

<!-- Example ID: 30f1d3fc-e267-4b30-84ef-4d9e7091ac1a --->

1\.

```py

>>> a = "some_string"

>>> id(a)

>>> id("some" + "_" + "string") # Ambas IDs son las mismas

```

2\.

```py

>>> a = "wtf"

>>> b = "wtf"

>>> a is b

>>> a = "wtf!"

>>> b = "wtf!"

>>> a is b

```

3\.

```py

>>> a, b = "wtf!", "wtf!"

>>> a is b # Todas las versiones excepto 3.7.x

>>> a = "wtf!"; b = "wtf!"

>>> a is b # Esto devolverá True o False dependiendo de en dónde lo estés invocando (consola Python / iPython / en un archivo)

```

```py

a = "wtf!"

b = "wtf!"

print(a is b)

```

4\.

**Output (< Python3.7)**

```py

>>> 'a' * 20 is 'aaaaaaaaaaaaaaaaaaaa'

>>> 'a' * 21 is 'aaaaaaaaaaaaaaaaaaaaa'

```

Tiene sentido, ¿cierto?

+ El comportamiento en la primera y segunda porción de código es debido a una optimización de CPython (llamada "string interning (internado)") que intenta usar objetos inmutables en algunos casos en vez de crear un nuevo objeto cada vez.

+ Luego de ser "internado" muchas variables pueden hacer referencia al mismo objeto string en memoria (salvando así memoria).

+ En las porciones de código de arriba, los strings son internados implícitamente. La decisión de cuando internar un string implícitamente depende de la implementación. Hay algunas reglas que se pueden usar para averiguar si un string será internado o no:

* Todos los strings con longitud 0 y 1 son internados.

* Los strings son internados en el tiempo de compilación (`wtf` será internado pero `''.join(['w', 't', 'f'])` no será internado).

* Los strings que no están compuestos de letras ASCII, dígitos o pisos bajos no son internados. Esto explica porqué `'wtf!'` no fue internado debido al `!`. La implementación de esta regla en CPython puede ser encontrada [aquí](https://github.com/python/cpython/blob/3.6/Objects/codeobject.c#L19).


+ Cuando `a` y `b` son asignadas a `"wtf!` en la misma línea, el intérprete de Python crea un nuevo objeto, para luego hacer referencia a la segunda variable al mismo tiempo. Si lo haces en líneas separadas, Python "no sabe" que ya existe `"wft!"` como un objeto (porque `"wtf!"` no está implícitamente internado debido a lo mencionado arriba). Es una optimización en el tiempo de compilación. Esta optimización no aplica a las versiones 3.7.x de CPython (clickea este [Issue])(https://github.com/satwikkansal/wtfpython/issues/100) para ver una discusión sobre esto).

+ Una unidad de compilación en un ambiente interactivo (como IPython) consiste en una sola declaración, donde consiste en un módulo entero en caso de módulos. `a, b = "wtf!", "wtf!"` es una sola declaración, mientras que `a = "wtf!"; b = "wtf!"` son dos declaraciones en una misma línea. Esto explica por qué las identidades son diferentes en `a = "wtf!"; b = "wtf!"`, y también explica por qué son las mismas cuando son invocadas en `some_file.py`.

+ El cambio abrupto en el output de la cuarta porción de código es debido a la [optimización peephole](https://en.wikipedia.org/wiki/Peephole_optimization), técnica conocida como "Constant folding". Esto significa que la expresión `'a'*20` es reemplazada por `'aaaaaaaaaaaaaaaaaaaa'` durante la compilación para salvar algunos ciclos de reloj durante el tiempo de ejecución. "Constant folding" solo ocurre en strings que tienen una longitud menor a 21. (¿Por qué? Imagina el tamaño del archivo `.pyc` generado como resultado de la expresión `'a'*10**10`). [Aquí](https://github.com/python/cpython/blob/3.6/Python/peephole.c#L288) está la implementación para esto mismo.

+ Nota: En Python 3.7, "Constant folding" fue movido del optimizador peephole al optimizador AST con algún cambio en la lógica, haciendo que la cuarta porción de código no funcione en Python 3.7. Puedes leer más acerca de este cambio [aquí](https://bugs.python.org/issue11549).

<!-- Example ID: 07974979-9c86-4720-80bd-467aa19470d9 --->

```py

>>> (False == False) in [False] # tiene sentido

>>> False == (False in [False]) # tiene sentido

>>> False == False in [False] # ¿ahora qué?

>>> True is False == False

>>> False is False is False

>>> 1 > 0 < 1

>>> (1 > 0) < 1

>>> 1 > (0 < 1)

```

Según https://docs.python.org/3/reference/expressions.html#membership-test-operations

> Formalmente, si a, b, c, ..., y, z son expresiones y op1, op2, ..., opN son operadores de comparación, entonces op1 b op2 c ... y opN z es equivalente a a op1 b y b op2 c y ... y opN z, excepto que cada expresión es evaluada al menos una vez.

Aunque puedas considerar tonto este comportamiento en los ejemplso de arriba, es fantástico cuando se aplica a cosas como `a == b == c` y `0 <= x <= 100`.

* `False is False is False` es equivalente a `(False is False) and (False is False)`

* `True is False == False` es equivalente a `True is False and False == False` y debido a que la primera parte de la declaración (`True is False`) devuelve `False`, la expresión completa devuelve `False`.

* `1 > 0 < 1` es equivalente a `1 > 0 and 0 < 1`, la cual devuelve `True`.

* La expresión `(1 > 0) < 1` es equivalente a `True < 1` y

```py

>>> int(True)

1

>>> True + 1 # no es relevante para este ejemplo

2

```

So, `1 < 1` devuelve `False`

<!-- Example ID: 230fa2ac-ab36-4ad1-b675-5f5a1c1a6217 --->

El código siguiente es un ejemplo muy famoso en el internet.

1\.

```py

>>> a = 256

>>> b = 256

>>> a is b

>>> a = 257

>>> b = 257

>>> a is b

```

2\.

```py

>>> a = []

>>> b = []

>>> a is b

>>> a = tuple()

>>> b = tuple()

>>> a is b

```

3\.

```py

>>> a, b = 257, 257

>>> a is b

```

**Output (Python 3.7.x específicamente)**

```py

>>> a, b = 257, 257

>> a is b

```

**La diferencia entre `is` y `==`**

* El operador `is` revisa si ambos operandos hacen referencia al mismo objeto (revisa si la identidad de los operandos combinan o no).

* El operador `==` compara los valores de ambos operandos y prueba si son iguales.

* Entonces, `is` es para la equidad de referencia y `==` para la equidad de valor. A continuación un ejemplo para hacer más clara la explicación,

```py

>>> class A: pass

>>> A() is A() # Estos son dos objetos diferentes en dos espacios de memoria diferentes.

False

```

**`256` es un objeto existente, pero `257` no lo es**

Cuando abres Python, los números desde el `-5` hasta el `256` son alocados. Estos números son usados un montón; es por esto que Python los prepara al comienzo.

Nota de https://docs.python.org/3/c-api/long.html

> La implementación actual mantiene un array de objetos de enteros para todos los enteros entre -5 y 256. Cuando creas un entero en ese rango, simplemente obtienes la referencia a ese objeto existente. Así que, debería ser posible cambiar el valor de 1. Creo que el comportamiento de Python en este caso es indefinido. :-)

```py

>>> id(256)

>>> a = 256

>>> b = 256

>>> id(a)

>>> id(b)

>>> id(257)

>>> x = 257

>>> y = 257

>>> id(x)

>>> id(y)

```

Aquí el intérprete no es tan inteligente al ejecutar `y = 257` para reconocer que ya hemos creado un entero con el valor `257` y crea un objeto nuevo y lo aloja en la memoria.

Una optimización similar ocurre a otros objetos **inmutables**, como tuples vacíos. Ya que las listas son mutables, `[] is []` devolverá `False` y `() is ()` devolverá `True`. Esto explica la segunda porción del código.

Ahora, veamos la tercera,

**Tanto `a` como `b` hacen referencia al mismo objeto cuando son inicializadas con el mismo valor en la misma línea.**

```py

>>> a, b = 257, 257

>>> id(a)

>>> id(b)

>>> a = 257

>>> b = 257

>>> id(a)

>>> id(b)

```

* Cuando se le asigna el valor `257` a `a` y `b` en la misma línea el intérprete de Python crea un nuevo objeto y hace referencia a la segunda variable al mismo tiempo. Si lo haces en líneas diferentes, el intérprete "no sabe" que ya existe `257` como un objeto.

* Es una optimización del compilador y específicamente aplica al ambiente interactivo. Cuando escriber dos líneas en un intérprete vivo, estas son compiladas por separado, lo que hace que sean optimizadas por separado. Si intentas escribir este ejemplo en un archivo `.py` verás que el comportamiento no es el mismo, ya las líneas en los archivos son compiladas de una sola vez. Esta optimización no se limita a enteros, también funciona para otros tipos de datos inmutables como strings (lee "Los strings son confusos") y tuples,

```py

>>> a, b = 257.0, 257.0

>>> a is b

True

```

* ¿Por qué no funciona en Python 3.7? La razón abstracta es que estas optimizaciones del compilador son específicas a la implementación (ej: varían según la versión, el sistema operativo, etc.). Todavía estoy investigando qué implementación causa este error. Puedes ver este [Issue](https://github.com/satwikkansal/wtfpython/issues/100) para más información.

<!-- Example ID: eb17db53-49fd-4b61-85d6-345c5ca213ff --->

1\.

```py

some_dict = {}

some_dict[5.5] = "JavaScript"

some_dict[5.0] = "Ruby"

some_dict[5] = "Python"

```

**Output:**

```py

>>> some_dict[5.5]

>>> some_dict[5.0] # ¿"Python" destruyó la existencia de "Ruby"?

>>> some_dict[5]

>>> complex_five = 5 + 0j

>>> type(complex_five)

>>> some_dict[complex_five]

```

¿Por qué está "Python" por todos lados?

* Las llaves en los diccionarios de Python funcionan por *equivalencia*, no por identidad. Aunque `5`, `5.0` y `5 + 0j` son objetos diferentes de tipos diferentes, ya que son iguales, no pueden estar en el mismo `dict` (o `set`). Cuando insertes cualquiera de ellos, al intentar tomar una llave distinta pero equivalente tomará en realidad un valor mapeado (en vez de devolver un `KeyError`):

```py

>>> 5 == 5.0 == 5 + 0j

True

>>> 5 is not 5.0 is not 5 + 0j

True

>>> some_dict = {}

>>> some_dict[5.0] = "Ruby"

>>> 5.0 in some_dict

True

>>> (5 in some_dict) and (5 + 0j in some_dict)

True

```

* Esto también aplica al declarar un elemento. Cuando escribes `some_dict[5] = "Python"`, Python encuentra el elemento existente con una llave equivalente `5.0 -> "Ruby"`, los reemplaza en el lugar y deja la llave original sin tocar.

```py

>>> some_dict

{5.0: 'Ruby'}

>>> some_dict[5] = "Python"

>>> some_dict

{5.0: 'Python'}

```

* Entonces, ¿cómo podemos actualizar la llave a `5` (en vez de `5.0`)? No podemos hacer esto en el lugar, pero lo que podemos hacer es: primero, borrar la llave (`del some_dict[5.0]`); luego, actualizarla (`some_dict[5]`) para obtener el entero `5` como la llave en vez del decimal `5.0` (aun así, esto no será necesario en la mayoría de los casos).

* ¿Cómo Python encontró `5` en un diccionario que contiene `5.0`? Python hace esto constantemente sin la necesidad de escanear cada uno de los elementos usando funciones hash. Por ejemplo, cuando Python busca una llave llamada `foo` en un diccionario, primero ejecuta `hash(foo)` (constantemente). Ya que en Python para que los objetos que se comparan por igual necesitan tener el mismo valor hash ([documentación](https://docs.python.org/es/3/reference/datamodel.html#object.__hash__)), `5`, `5.0` y `5 + 0j` tienen el mismo valor hash.

```py

>>> 5 == 5.0 == 5 + 0j

True

>>> hash(5) == hash(5.0) == hash(5 + 0j)

True

```

**Nota:** lo contrario no es necesariamente cierto: los objetos con el mismo valor hash pueden ser desiguales. (Esto causa lo que es conocido como una [colisión hash](https://es.wikipedia.org/wiki/Colisi%C3%B3n_(hash))) y degrada el tiempo de rendimiento que el hash provee).

<!-- Example ID: 8f99a35f-1736-43e2-920d-3b78ec35da9b --->

```py

class WTF:

pass

```

**Output:**

```py

>>> WTF() == WTF() # dos instancias diferentes no pueden ser iguales

>>> WTF() is WTF() # las identidades también son diferentes

>>> hash(WTF()) == hash(WTF()) # los hash también deberían ser diferentes

>>> id(WTF()) == id(WTF())

```

* Cuando `id` es llamada, Python crea un objeto de la clase `WTF` y la pasa a la función `id`. La función `id` toma su `id` (su espacio en memoria) y desecha el objeto (lo destruye).

* Cuando hacemos estos dos veces en una sucesión, Python asigna el mismo espacio en memoria al segundo objeto también. Ya que `id` usa el espacio de memoria como la identificación del objeto (en CPython), la identificación de ambos objetos es la misma.

* Es por esto que la identificación del objeto es única solo mientras el objeto existe. Cuando el objeto es destruido o antes de que sea creado, cualquier otro objeto puede tener la misma identificación.

* Pero, ¿por qué el operador `is` devolvió `False`? Veamos la respuesta en esta porción de código.

```py

class WTF(object):

def __init__(self): print("I")

def __del__(self): print("D")

```

**Output:**

```py

>>> WTF() is WTF()

I

I

D

D

False

>>> id(WTF()) == id(WTF())

I

D

I

D

True

```

Como puedes ver, el orden en el que los objetos son destruidos es la causa de la diferencia ocurrida.

<!-- Example ID: 91bff1f8-541d-455a-9de4-6cd8ff00ea66 --->

```py

from collections import OrderedDict

dictionary = dict()

dictionary[1] = 'a'; dictionary[2] = 'b';

ordered_dict = OrderedDict()

ordered_dict[1] = 'a'; ordered_dict[2] = 'b';

another_ordered_dict = OrderedDict()

another_ordered_dict[2] = 'b'; another_ordered_dict[1] = 'a';

class DictWithHash(dict):

"""

__hash__ = lambda self: 0

class OrderedDictWithHash(OrderedDict):

"""

__hash__ = lambda self: 0

```

```py

>>> dictionary == ordered_dict # Si a == b

>>> dictionary == another_ordered_dict # y b == c

>>> ordered_dict == another_ordered_dict # entonces, ¿por qué c no es igual a a (c == a)?

>>> len({dictionary, ordered_dict, another_ordered_dict})

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

TypeError: unhashable type: 'dict'

>>> dictionary = DictWithHash()

>>> dictionary[1] = 'a'; dictionary[2] = 'b';

>>> ordered_dict = OrderedDictWithHash()

>>> ordered_dict[1] = 'a'; ordered_dict[2] = 'b';

>>> another_ordered_dict = OrderedDictWithHash()

>>> another_ordered_dict[2] = 'b'; another_ordered_dict[1] = 'a';

>>> len({dictionary, ordered_dict, another_ordered_dict})

>>> len({ordered_dict, another_ordered_dict, dictionary}) # cambiando el orden

```

¿Qué está ocurriendo aquí?

- La razón por la cual la equidad intransitiva no es soportada entre `dictionary`, `ordered_dict` y `another_ordered_dict` radica en la forma en que el método `__eq__` está implementado en la clase `OrderedDict`. Información de la [documentación](https://docs.python.org/es/3/library/collections.html#ordereddict-objects).

> Las pruebas de equidad entre los objetos OrderedDict dependen del orden y son implementados como `list(od1.items())==list(od2.items())`. Estas pruebas aplicadas a estos objetos (al igual que a otros objetos de mapeo) no dependen del orden (al igual que los diccionarios regulares).

- La razón de esta equidad en el comportamiento permite a los objetos `OrderedDict` a ser sustituidos directamente en cualquier lugar del código en donde un diccionario regular sea usado.

- Entonces, ¿por qué al cambiar el orden se afecta la longitud del objeto `set` generado? La respuesta es que solo está presenta la equidad intransitiva. Ya que los sets son colecciones "desordenadas" de elementos únicos, el orden en el que los elementos son insertados no debería importar. Pero, en este caso si importa. Veamos el porqué,

```py

>>> some_set = set()

>>> some_set.add(dictionary) # estos son los objetos de mapeo de las porciones de código de arriba

>>> ordered_dict in some_set

True

>>> some_set.add(ordered_dict)

>>> len(some_set)

1

>>> another_ordered_dict in some_set

True

>>> some_set.add(another_ordered_dict)

>>> len(some_set)

1

>>> another_set = set()

>>> another_set.add(ordered_dict)

>>> another_ordered_dict in another_set