Operadores relacionales y lógicos en Python: ==, !=, <, and, or y not

Los operadores relacionales comparan dos valores y responden siempre con True o False. Son seis: == (igual), != (distinto), < (menor), <= (menor o igual), > (mayor) y >= (mayor o igual). Los operadores lógicos, and, or y not, combinan respuestas de ese tipo: and pide que las dos sean verdaderas, or pide que al menos una lo sea, y not invierte el valor. Juntos, forman las condiciones que hacen que el programa elija entre caminos.

Es la parte de la programación que más se parece a lo que hacemos todo el día sin pensar. Antes de salir de casa, comparas la hora con la de la reunión, miras si está lloviendo y decides por dónde ir. Este artículo muestra cómo escribe Python cada una de esas preguntas, dónde sorprende, qué cambia en la ESP32 y cómo el mismo razonamiento sirve para elegir una ruta y para recalcular cuando el camino cambia.

El problema: la pregunta que el programa necesita responder

Piensa en la aplicación de mapas de tu celular. Mientras manejas, repite decenas de preguntas de sí o no: ¿el tiempo restante pasó de lo previsto? ¿Hay una vía cortada más adelante? ¿Existe un camino alternativo que llegue antes? ¿Alcanza el combustible para hacer el desvío? Cada pregunta tiene como respuesta un "sí" o un "no", y es la combinación de ellas la que decide si la aplicación mantiene la ruta o propone otra.

Un programa hace lo mismo, solo que con valores guardados en variables. La lectura de un sensor de temperatura, la distancia medida por un ultrasonido, el texto escrito por alguien: todo eso se vuelve pregunta cuando se compara con otro valor. Y la respuesta no es un texto ni un número, es un valor de un tipo aparte, el bool, que solo acepta dos valores, True y False. Quien entiende ese tipo y las operaciones sobre él consigue escribir cualquier decisión, de la más simple a la más llena de excepciones.

Las seis comparaciones

print(3 == 3.0, 3 != 4, 5 > 3, 2 <= 2, 7 < 7, 7 >= 8)
print("5" == 5, 5 == 5.0, True == 1, None == 0)
print(type(3 > 2), int(3 > 2), True + True)

La primera línea da True True True True False False, y cada valor responde a una de las comparaciones. Fíjate en el primero: 3 == 3.0 es verdadero. Python compara el valor, no el tipo, así que un entero y un decimal que representan el mismo número son iguales. En la segunda línea aparece lo contrario: "5" == 5 es False, porque un texto y un número nunca son iguales, aunque se escriban igual en la pantalla. Esa es la misma lección del artículo sobre conversión de tipos, ahora aplicada a comparaciones.

La tercera línea muestra el tipo del resultado, <class 'bool'>, y que el booleano se comporta como número en una cuenta: int(3 > 2) vale 1 y True + True vale 2. Esto es útil para contar cuántas condiciones fueron verdaderas, y es la razón por la que True == 1 también da True.

El signo igual: uno para guardar, dos para preguntar

La confusión más antigua de la programación cabe en una línea. El signo = guarda un valor en un nombre. El signo == pregunta si dos valores son iguales. Quien escribe x = 5 está diciendo "x pasa a valer 5". Quien escribe x == 5 está preguntando "¿x vale 5?", y la respuesta es True o False. En un if, tema de un artículo próximo, usar el signo equivocado impide que el programa corra:

x = 5
if x = 5:
    print("ok")

SyntaxError: invalid syntax

El error es de sintaxis, y aparece antes de que cualquier línea corra. En las versiones recientes del Python del computador el mensaje incluso sugiere la corrección (Maybe you meant '==' or ':=' instead of '='?). MicroPython solo dice invalid syntax, y hay que recordar por cuenta propia la diferencia entre un signo y dos.

Comparando textos

Los textos también se comparan, y el orden sigue la tabla de caracteres del computador, no la del diccionario.

print("a" == "a", "a" < "b", "Z" < "a", "abc" < "abd", "10" < "9", "Casa" == "casa")
print("Casa".lower() == "casa", "ab" < "abc", "" < "a")
print(ord("Z"), ord("a"), ord("1"))

La primera línea da True True True True True False. Los dos últimos valores merecen atención. "10" < "9" es verdadero, porque Python compara carácter por carácter: el primero de "10" es "1", que viene antes que "9" en la tabla, y la comparación termina ahí, sin mirar el cero. Y "Casa" == "casa" es falso, porque la letra mayúscula y la minúscula son caracteres distintos. En la tercera línea, ord() muestra el número de cada carácter: Z vale 90 y a vale 97, y por eso "Z" < "a" es verdadero y todas las mayúsculas vienen antes que todas las minúsculas. Cuando lo que importa es el contenido, y no la caja, la salida es convertir los dos lados con .lower() antes de comparar, como hace la segunda línea.

El caso de las notas leídas del teclado muestra el riesgo de comparar texto como si fuera número:

a = input("A: ")
b = input("B: ")
print(a < b, int(a) < int(b), a == "10", int(a) == 10)

Escribiendo 10 y 9, la salida es:

A: 10
B: 9
True False True True

La comparación de los textos dice que "10" viene antes que "9", y la de los números dice lo contrario. Quien olvidó convertir el input() recibe una respuesta sin error y sin sentido.

Comparando decimales

Con decimales, el == pide cuidado, porque muchos números como 0,1 no existen exactamente en binario y la cuenta guarda un residuo mínimo:

print(0.1 + 0.2 == 0.3, abs(0.1 + 0.2 - 0.3) < 1e-6)
print(1.1 + 2.2 == 3.3, abs(1.1 + 2.2 - 3.3) < 0.001)

En el simulador, la salida es True True y False True. En el Python del computador, la primera línea da False True. La misma comparación 0.1 + 0.2 == 0.3 responde distinto según el número de bits del float, y la segunda (1.1 + 2.2 == 3.3) da falso en los dos. Ninguna de las respuestas es confiable: el == entre decimales calculados depende de la suerte. Lo que funciona en las dos máquinas es comparar la diferencia con una tolerancia, abs(a - b) < 0.001, que es la segunda comparación de cada línea, y da True en todos los casos.

Comparación encadenada y los operadores in e is

Python acepta escribir un rango de valores como se escribe en la matemática, con la variable en el medio de dos comparaciones:

x = 7
print(1 < x < 10, 10 <= x < 20, 0 < x < 5 < 10)
print(1 < x and x < 10, 5 < x > 6)
print("a" in "banana", "z" in "banana", 3 in [1, 2, 3], "ana" in "banana", 4 not in [1, 2, 3])
y = None
print(y is None, y is not None, y == None)
print(not x == 5, x != 5, not (x == 5))

La primera línea da True False False. 1 < x < 10 equivale a 1 < x and x < 10, que es la primera expresión de la línea siguiente, y es la forma más legible de decir "x está entre 1 y 10". Funciona con cuantas comparaciones quieras, y 5 < x > 6 también es válido (vale True para el 7), pero nadie lo lee sin detenerse a pensar. En la tercera línea aparece el in, que pregunta si un texto contiene a otro ("ana" in "banana") o si un valor está en una colección, y el not in, que hace la pregunta inversa. El is None compara con el valor especial None, que quiere decir "nada", y es la forma recomendada de probarlo. En las dos últimas líneas, not x == 5 y x != 5 dan la misma respuesta, y el segundo es más fácil de leer.

Los tres operadores lógicos

El and es verdadero solo cuando los dos lados lo son. El or es verdadero cuando al menos uno de los lados lo es, y solo da falso cuando ambos son falsos. El not invierte. Para tres operadores, el orden en que Python los resuelve es fijo: primero el not, después el and, por último el or.

print(True and True, True and False, False or True, False or False, not True, not False)
print(True or False and False, (True or False) and False)
print(not True or True, not (True or True))
print(1 < 2 and 2 < 3, 1 < 2 or 1 / 1 > 0)

La primera línea comprueba las combinaciones de la figura: True False True False False True. La segunda es la que suele engañar. True or False and False vale True, porque el and se resuelve antes: False and False da False, y True or False da True. Con paréntesis, (True or False) and False vale False. En la tercera línea, not True or True se lee como (not True) or True y da True, mientras que not (True or True) da False. Escribir las condiciones con paréntesis no cuesta nada y deja la intención visible, el mismo consejo del artículo sobre operadores aritméticos.

El cortocircuito

Python no hace el trabajo que no necesita hacer. En un and, si el lado izquierdo ya es falso, el resultado es falso y el lado derecho ni se calcula. En un or, si el lado izquierdo ya es verdadero, el derecho se ignora.

print(False and (1 / 0 > 1))
print(True or (1 / 0 > 1))
divisor = 0
print(divisor != 0 and 10 / divisor > 2)

La salida es False, True y False, sin ningún error, aunque 1 / 0 levantaría ZeroDivisionError si se calculara. Esto permite un patrón de protección muy usado: poner a la izquierda la pregunta que garantiza que la cuenta de la derecha es segura. En la tercera línea, como divisor != 0 es falso, la división 10 / divisor nunca corre. Si el orden fuera el inverso, el programa se rompería.

El and y el or devuelven uno de los lados, no solo True o False

Hay un detalle que sorprende a quien viene de otros lenguajes: el and y el or devuelven uno de los dos valores originales, no necesariamente un booleano. El or devuelve el primer valor que Python considera verdadero, o el último, si ninguno lo es. El and devuelve el primer valor falso, o el último, si todos son verdaderos.

print(0 or "defecto", "" or "anónimo", "Ana" or "anónimo")
print(5 and 7, 0 and 7, 5 or 7, None or 0)
print(not 0, not "", not [], not "0", not 5, not None)

La primera línea da defecto anónimo Ana, y muestra un uso práctico: nome or "anónimo" entrega el nombre cuando existe y un valor por defecto cuando está vacío. La segunda da 7 0 5 0. La tercera muestra que el not siempre devuelve booleano: True True True False False True. Los valores "falsos" son el cero, el texto vacío, la lista vacía y el None. Todo lo demás cuenta como verdadero, incluido el texto "0", que no está vacío y por eso hace que not "0" sea igual a False.

Ejemplo trabajado: recalcular la ruta

Volviendo a la aplicación de mapas: debe proponer una nueva ruta cuando haya atraso o una vía cortada, pero solo si existe una alternativa que el combustible permita. En lenguaje de programa, son tres preguntas y dos puertas lógicas.

minutos_previstos = 30
minutos_agora = 47
via_interditada = False
combustivel_km = 40
distancia_alternativa_km = 55
atraso = minutos_agora > minutos_previstos * 1.25
alternativa_viavel = distancia_alternativa_km <= combustivel_km
recalcular = (atraso or via_interditada) and alternativa_viavel
print(minutos_previstos * 1.25, atraso, alternativa_viavel, recalcular)
print(atraso or via_interditada and alternativa_viavel)
combustivel_km = 60
alternativa_viavel = distancia_alternativa_km <= combustivel_km
print(alternativa_viavel, (atraso or via_interditada) and alternativa_viavel)
via_interditada = True
minutos_agora = 28
atraso = minutos_agora > minutos_previstos * 1.25
print(atraso, via_interditada, (atraso or via_interditada) and alternativa_viavel)

La salida es 37.5 True False False, True, True True y False True True. En la primera línea, el límite de atraso es 37,5 minutos (30 más 25%), y el trayecto ya está en 47, así que atraso es verdadero. Pero la alternativa tiene 55 km y el combustible solo alcanza para 40, entonces alternativa_viavel es falso y recalcular cierra en False: no sirve proponer un desvío imposible.

La segunda línea es la que el diagrama muestra en rojo. Sin los paréntesis, el and se resuelve antes, y la expresión pasa a ser "hay atraso, o (la vía está cortada y la alternativa es viable)". Como hay atraso, el resultado es True, y la aplicación mandaría al conductor a un desvío sin combustible. Con los paréntesis, la respuesta es la correcta. Es el error de precedencia del artículo anterior, ahora con consecuencia.

Después de cargar combustible (60 km de combustible), la tercera línea muestra True True: la alternativa pasa a ser viable y recalcular cierra en verdadero. La última línea cambia el escenario: el tiempo volvió a la normalidad, atraso es falso, pero la vía quedó cortada. El resultado sigue siendo True, y es el or el que lo garantiza: cualquiera de los dos motivos basta.

Eligiendo entre rutas

Cuando existen tres caminos, la decisión es comparar los tiempos. El detalle está en elegir entre < y <=:

tempo_a = 34
tempo_b = 29
tempo_c = 29
print(tempo_a < tempo_b, tempo_b == tempo_c, tempo_b <= tempo_c, min(tempo_a, tempo_b, tempo_c))
print(tempo_b < tempo_a and tempo_b < tempo_c, tempo_b <= tempo_a and tempo_b <= tempo_c)

La salida es False True True 29 y False True. La ruta B es la más rápida, pero empata con la C. Preguntar "¿B es estrictamente la mejor?" (< en las dos comparaciones) da False, porque en el empate ninguna es mejor que la otra. Preguntar "¿B es al menos tan buena como las otras?" (<=) da True. Las dos preguntas están bien y responden cosas distintas, y el error está en usar una cuando el problema pedía la otra.

Qué cambia en la ESP32

Los operadores se comportan igual en MicroPython y en el Python del computador. La diferencia está en dos lugares. El primero es el float de 32 bits, que ya apareció en el artículo sobre variables y tipos: comparar decimales con == puede dar respuestas distintas en cada máquina, como se vio arriba. En la ESP32 el problema es mayor, porque el valor viene de un sensor, y las lecturas de temperatura o de distancia casi nunca se repiten de forma exacta. En lugar de temperatura == 25.0, escribe un rango: 24.5 <= temperatura <= 25.5. El segundo lugar es el mensaje de error de una comparación que no tiene sentido:

El == y el != nunca dan TypeError: "5" == 5 simplemente vale False. Solo las comparaciones de orden (<, <=, >, >=) exigen tipos que se puedan ordenar entre sí. Esto explica por qué un programa puede correr durante horas con un texto en lugar de un número y solo romperse cuando llega a la primera comparación de orden.

En las placas, las lecturas digitales también entran en las condiciones. El valor de un pin leído con pin.value() es 0 o 1, y pin.value() == 1 es una comparación como las demás. El artículo sobre sensores muestra cómo esos valores llegan del hardware.

Experiencia de aula: qué ruta seguir y cuándo recalcular

Hay una actividad que funciona bien para fijar estos operadores, porque parte de algo que todos ya vivieron: el trayecto a la escuela o al trabajo. La propuesta para el grupo es listar, antes de escribir una línea de código, las preguntas que una aplicación de rutas necesita responder. La lista que sale suele tener siempre el mismo formato, y cada ítem se vuelve una condición.

Elegir la mejor ruta. La persona compara el tiempo de tres caminos y elige el menor. Es un min() o una cadena de <. La discusión interesante viene del empate: si dos caminos tardan 29 minutos, ¿cuál de los dos es "el mejor"? El grupo percibe que la respuesta depende de un segundo criterio (distancia, peaje, semáforos), y que eso es un and o un or más en la condición.

Recalcular cuando algo cambia. Un tráfico que no estaba previsto, una vía cerrada, un accidente. El programa necesita una condición que se vuelva verdadera cuando cualquiera de esos motivos aparezca, y eso es un or. En cambio, la pregunta "¿hay un desvío posible?" es un and: solo vale desviarse si el desvío existe y cabe en el combustible. El grupo reproduce el ejemplo del diagrama con sus propios números.

No cambiar de ruta por cualquier diferencia. Si la aplicación cambiara de camino cada vez que el otro quedara un minuto más rápido, el conductor pasaría el viaje entero girando de calle. La solución es comparar con un margen:

tempo_rota_atual = 34
tempo_rota_nova = 31
margem = 5
print(tempo_rota_nova < tempo_rota_atual, tempo_rota_nova < tempo_rota_atual - margem)
tempo_rota_nova = 27
print(tempo_rota_nova < tempo_rota_atual, tempo_rota_nova < tempo_rota_atual - margem)

La salida es True False y después True True. Con la ruta nueva 3 minutos más rápida, la comparación simple dice "cambia" y la que usa margen dice "quédate". Solo cuando la ganancia pasa de 5 minutos el cambio compensa. El mismo razonamiento vale para un termostato, que no enciende y apaga el ventilador con cada lectura que oscila medio grado, y para cualquier sensor con ruido. Es uno de los usos más prácticos del < con una cuenta dentro.

El mismo problema en una placa. La actividad cierra cuando el grupo cambia el auto por un robot con un sensor de distancia al frente y otros dos a los lados. Las preguntas son las mismas: ¿hay obstáculo? ¿Se puede desviar hacia la izquierda? ¿Y hacia la derecha? Y si ninguno de los lados está libre, el robot se detiene.

distancia_frente = 15
distancia_esq = 40
distancia_dir = 25
obstaculo = distancia_frente < 20
livre_esq = distancia_esq > 30
livre_dir = distancia_dir > 30
desviar_esq = obstaculo and livre_esq
desviar_dir = obstaculo and not livre_esq and livre_dir
parar = obstaculo and not livre_esq and not livre_dir
print(obstaculo, livre_esq, livre_dir)
print(desviar_esq, desviar_dir, parar)
distancia_esq = 20
livre_esq = distancia_esq > 30
desviar_esq = obstaculo and livre_esq
desviar_dir = obstaculo and not livre_esq and livre_dir
parar = obstaculo and not livre_esq and not livre_dir
print(desviar_esq, desviar_dir, parar)
distancia_dir = 45
livre_dir = distancia_dir > 30
desviar_esq = obstaculo and livre_esq
desviar_dir = obstaculo and not livre_esq and livre_dir
parar = obstaculo and not livre_esq and not livre_dir
print(desviar_esq, desviar_dir, parar)

La salida tiene cuatro líneas: True True False, True False False, False False True y False True False. La primera dice que hay obstáculo, que la izquierda está libre y que la derecha no lo está. La segunda muestra el resultado, y el robot se desvía a la izquierda. Con la izquierda a 20 cm, deja de estar libre y la derecha sigue bloqueada, entonces solo parar vale True. Con la derecha a 45 cm, el desvío pasa a ser por la derecha. Fíjate en que cada escenario activa exactamente una de las tres salidas. Ese es el examen que el grupo aprende a hacer: las condiciones no pueden superponerse (dos acciones al mismo tiempo) ni dejar un caso afuera (ninguna acción). Quien olvida el not livre_esq en desviar_dir descubre el problema en el primer escenario en que los dos lados están libres.

Errores que comete hasta quien programa hace años

El ejemplo de las rutas expone algunos de los tropiezos más comunes, y ninguno es exclusivo de principiantes.

• Olvidar el caso "ninguna alternativa". Quien escribe las condiciones para izquierda y derecha suele olvidar decir qué hacer cuando las dos fallan. El robot sigue de frente contra la pared.
• Condiciones que se superponen. Dos rutas "mejores" al mismo tiempo, dos desvíos verdaderos. En general nace de usar <= donde bastaba <, o de olvidar un not.
• Mezclar and y or sin paréntesis. El caso del diagrama, que aparece en código de producción. La regla de oro: si hay and y or en la misma expresión, pon paréntesis, aunque el resultado coincida con el orden de Python.
• Comparar decimal con ==. Una altura, una distancia y una temperatura calculadas nunca deben probarse por igualdad exacta. Usa un rango o una tolerancia.
• El or con un valor suelto. Quien escribe cidade == "SP" or "RJ" imagina estar comparando con dos ciudades. Python lo lee como (cidade == "SP") or "RJ", y el texto "RJ" es siempre verdadero. Es el error que más pasa desapercibido, y el ejemplo está justo debajo.

x = 5
print(x == 1 or 2)
print(x == 5 or 2)
print(x in (1, 2), x in (4, 5))

La salida es 2, True y False True. Para x valiendo 5, la primera expresión no da False, da el número 2, que cuenta como verdadero en una decisión. La corrección es repetir la variable (x == 1 or x == 2) o usar in, como en la tercera línea.

Ejercicio: la ruta con peaje

Hay tres caminos al mismo destino. El A tarda 34 minutos, el B tarda 29 y tiene peaje, y el C tarda 31. El conductor solo acepta pagar el peaje si el ahorro sobre el mejor camino sin peaje es de al menos 5 minutos. Escribe las dos preguntas en Python: si el camino sin peaje más rápido es el C, y si el B vale la pena. Después cambia el tiempo del B a 24 y mira si la respuesta cambia.

Piensa primero: el mejor camino sin peaje es el menor tiempo entre A y C. El B vale la pena cuando su tiempo es menor o igual a ese mejor menos 5.

tempo_a = 34
tempo_b = 29
tempo_c = 31
sem_pedagio_melhor = tempo_c < tempo_a
b_vale_a_pena = tempo_b <= min(tempo_a, tempo_c) - 5
print(sem_pedagio_melhor, b_vale_a_pena)
tempo_b = 24
b_vale_a_pena = tempo_b <= min(tempo_a, tempo_c) - 5
print(b_vale_a_pena)

La salida es True False y después True. El mejor camino sin peaje tarda 31 minutos, y el B con 29 solo ahorra 2, así que no compensa. Con 24 minutos el ahorro sube a 7, y supera el margen de 5. Una buena prueba es poner el tiempo del B en 26, exactamente en el límite, y comprobar cuál de las dos comparaciones, < o <=, da el resultado que pide el enunciado.

Preguntas frecuentes

¿Cuál es la diferencia entre = y ==?

El = guarda un valor en un nombre: x = 5. El == compara dos valores y responde True o False: x == 5. En un if, usar = en lugar de == da SyntaxError.

¿Puedo comparar un texto con un número?

Con == y !=, sí: el resultado es False y True, porque son tipos distintos. Con <, <=, > y >=, no: Python levanta TypeError. Convierte antes, con int() o float().

¿El and es igual al &?

No. El and es el operador lógico, que trabaja con condiciones y hace cortocircuito. El & es un operador bit a bit, que opera sobre los bits de los números enteros. Para condiciones, usa siempre and y or.

¿Cuándo usar is en lugar de ==?

El == compara valores. El is compara si dos nombres apuntan al mismo objeto. Para el día a día, usa is solo con None (x is None) y == para todo lo demás.

Para continuar

La ruta Lógica con Python tiene desafíos que ejercitan cada comparación. El Comparar textos trabaja == con texto, el Mayor de edad y el Par o impar usan >= y == con el resto de la división, y el Intervalo de 10 a 20 exige el rango con and. Si algún concepto quedó suelto, los artículos sobre entrada y salida y sobre conversión de tipos explican de dónde vienen los valores que aquí se comparan.

El próximo tema son las tablas de verdad en la práctica: cómo armar, a partir de cualquier expresión con and, or y not, la lista de todos los casos posibles, y cómo comprobar con ella si dos condiciones que parecen distintas dicen lo mismo.