
IB Python: Traducir pseudocódigo sin confundirte
Exploramos cómo reconocer el patrón input-process-output y traducir condicionales, bucles, funciones y listas de pseudocódigo a Python sin perder puntos en el examen.
También revisamos errores típicos como el range en Python, los índices desde cero y cómo leer el código por bloques para entender la lógica con más claridad.
Chapter 1
El truco que más confunde en programación IB
Diego Salazar
[excited] Welcome to the show. Lucía, te tiro una escena de examen: lees “IF mark >= 50 THEN output ‘Pass’ ELSE output ‘Fail’”, y medio grupo entra en pánico... aunque eso en Python son DOS líneas y una indentación.
Lucía Navarro
[warmly] Y esa palabra, “THEN”, es justo la trampa. Mucha gente ve “IF... THEN...” y lo lee como inglés normal, como si estuviera narrando algo. Pero no. “THEN” significa: abre bloque. En Python, tu cerebro debería oír casi automáticamente: “if mark >= 50:” y debajo un bloque indentado.
Diego Salazar
Exacto. Yo lo pienso como una receta del café de mi familia. Entrada: llega el pedido. Proceso: decides qué preparar. Salida: entregas el café. En examen, aunque te lo escriban en pseudocódigo elegante, casi siempre te están escondiendo el mismo patrón de cocina: INPUT, PROCESS, OUTPUT.
Lucía Navarro
[questioning tone] Ese “INPUT, PROCESS, OUTPUT” me gusta porque baja la ansiedad. Si una línea dice “READ name”, tú no necesitas discutir con la sintaxis oficial del pseudocódigo. Solo pensar: vale, esto es una entrada. En Python sería algo como “name = input()”. Y si luego dice “DISPLAY name”, salida. “print(name)”.
Diego Salazar
[responds quickly] Sí, y aquí va la parte práctica: no memorices veinte formatos raros. Reconoce el PATRÓN. Variable, decisión, repetición, función. Si identificas esas cuatro piezas, ya hiciste la mitad del trabajo.
Lucía Navarro
[calm] Bueno... mitad, pero no toda. Porque otra cosa que veo mucho con estudiantes de IB es que reconocen la idea, pero no la organizan. Ven cinco líneas de pseudocódigo y las interpretan una por una. Yo les digo: no leas línea por línea; lee por bloques. ¿Dónde empieza el condicional? ¿Dónde termina el bucle? ¿Qué variable cambia?
Diego Salazar
[skeptical] Y ahí es donde Python ayuda más que memorizar definiciones. Porque Python te obliga a ver BLOQUES. Si te imaginas el pseudocódigo con indentación, muchas confusiones desaparecen. “FOR i <- 1 TO 5” deja de ser una frase rara y se vuelve “for i in range(1, 6):”.
Lucía Navarro
[interrupts] Espera, ese “6” en “range(1, 6)” es el detalle que luego duele. Porque en pseudocódigo, “1 TO 5” incluye el 5. En Python, el segundo número de “range” NO se incluye. Ese 6 es de las cosas que más puntos cuestan por un despiste pequeño.
Diego Salazar
[laughs softly] Sí, ese es el clásico. Como contar sillas para una mesa de 5 personas y dejar fuera a la última porque te confundiste con dónde termina la fila. Y otra: si el pseudocódigo dice “SET total TO total + price”, en Python tu cabeza debe oír “total = total + price”. No “total + price = total”, no cosas creativas.
Lucía Navarro
[reflective] En realidad, lo que buscamos es traducción mental, no traducción literal. No hace falta que cada palabra del pseudocódigo tenga una palabra gemela en Python. Hace falta que el significado quede claro. “WHILE total < 100” no se traduce palabra por palabra; se traduce como una estructura que repite mientras una condición siga siendo verdadera.
Diego Salazar
Y si eres de los que lee pseudocódigo como si fuera un párrafo, prueba esto en el examen: marca con lápiz tres cosas. Entrada, proceso, salida. Por ejemplo: “INPUT age”, entrada. “IF age >= 18”, proceso de decisión. “OUTPUT 'Adult'”, salida. De golpe deja de parecer un idioma alienígena.
Lucía Navarro
[warmly] Y hay un alivio real ahí. Porque el examen no te está preguntando si eres poeta del pseudocódigo. Te está preguntando si entiendes la lógica. Y la lógica, honestamente, suele verse más limpia cuando la imaginas en Python.
Chapter 2
Pseudocódigo a Python sin perder puntos
Lucía Navarro
[excited] Vamos con equivalencias concretas, rapiditas. Si ves “IF condition THEN ... ELSE ...”, piensa: “if condicion:” y luego “else:”. Si ves “FOR counter <- 1 TO 3”, piensa: “for counter in range(1, 4):”. Si ves “WHILE x > 0”, pues “while x > 0:”. Y si aparece una colección como “numbers[2]”, en Python también sería acceso por índice, aunque ahí sí hay que tener cuidado con si el contexto usa índices desde 0.
Diego Salazar
[questioning tone] Ese detalle de índices desde 0... uff. Si el examen te da una lista de 5 elementos y habla del “primer elemento”, en Python eso es índice 0, no 1. Es como las mesas en una biblioteca: el “primer asiento” no es el asiento número 1 en tu cabeza de programador, es la posición 0 en Python.
Lucía Navarro
[chuckles] Tal cual. Y con funciones, misma idea. Si el pseudocódigo dice “FUNCTION double(x) RETURN x * 2”, en Python sería: “def double(x):” y debajo “return x * 2”. Lo importante no es si recuerdas la palabra exacta usada en el pseudocódigo; lo importante es que reconoces entrada de parámetros, proceso y valor devuelto.
Diego Salazar
Déjame hacer de estudiante estresado. [hesitates] “Ok, Lucía, yo entiendo IF y FOR. Pero en el examen me ponen algo mini, raro, como: READ 4 numbers, store them in a list, then output the largest.” Y me bloqueo.
Lucía Navarro
[matter-of-fact] Bien. Lo troceamos. “READ 4 numbers”: entrada repetida cuatro veces. “Store them in a list”: necesitas una lista, por ejemplo “numbers = []”. “Output the largest”: puedes recorrer la lista y comparar. En Python limpio, sería algo así: empiezas con “numbers = []”, luego “for i in range(4):”, dentro haces “n = int(input())” y “numbers.append(n)”. Después, “largest = numbers[0]”. Recorres la lista, y si un valor es mayor que “largest”, actualizas. Al final, “print(largest)”.
Diego Salazar
[reacting quickly] Ese “largest = numbers[0]” es buenísimo porque evita otro error clásico: empezar con 0 porque sí. Si los 4 números fueran -3, -8, -2 y -10, arrancar con 0 te daría un resultado falso. El 0 ni siquiera estaba en la lista.
Lucía Navarro
[pleased] Exacto. Ese “-3, -8, -2, -10” es un caso límite perfecto. Y aquí entra una idea muy de examen: no basta con que el código funcione en el ejemplo bonito. Tiene que funcionar en casos feos también.
Diego Salazar
[skeptical] A ver, voy a explicarlo de vuelta, a ver si lo tengo. Si el pseudocódigo dice “FOR each item in list”, entonces siempre hago un “while”, ¿no? Porque ambas repiten.
Lucía Navarro
[gentle correction] Casi. Repiten las dos, sí, pero no son intercambiables sin pensar. “FOR each item in list” en Python se ve mucho más natural como “for item in lista:”. El “while” sirve mejor cuando no sabes cuántas veces vas a repetir y dependes de una condición que cambia, como “while password != correcta” o “while total < 100”.
Diego Salazar
[short pause] Vale, o sea: FOR cuando el recorrido está bastante definido; WHILE cuando dependes de que algo siga siendo verdad. Eso sí se me queda.
Lucía Navarro
Y en listas, otro puente útil. Si el pseudocódigo hace “ADD score TO scores”, en Python piensas “scores.append(score)”. Si hace “REMOVE”, en Python ya dependerá de si quitas por valor o por posición, pero al menos reconoces la intención: la lista cambia.
Diego Salazar
[curious] ¿Y con un condicional más realista de examen? Algo tipo descuento de tienda, que siempre ayuda.
Lucía Navarro
[warmly] Perfecto. Pseudocódigo: “INPUT total. IF total >= 100 THEN discount <- 10 ELSE discount <- 0. OUTPUT total - discount.” En Python: “total = float(input())”. Luego “if total >= 100:”, debajo “discount = 10”, y en “else:” pones “discount = 0”. Al final, “print(total - discount)”. Limpio, legible, y cada bloque hace una sola cosa.
Diego Salazar
[laughs] Y si alguien intenta poner “if total => 100”... pues no. Ese símbolo al revés es como poner la llave del café del lado incorrecto. Parece casi igual, pero no abre nada.
Lucía Navarro
[trying not to laugh] Sí, y ahí entramos en los fallos más comunes. Uno: indentación. En Python, la indentación NO es decoración; define el bloque. Dos: condiciones mal planteadas, como usar “>” cuando necesitabas “>=” y dejar fuera exactamente el valor frontera, como 100. Tres: no probar casos límite: 0, negativos, lista vacía, valor exacto del umbral.
Diego Salazar
Ese “100” me gusta porque es el típico borde. Si la regla dice “100 o más”, el 100 tiene que entrar. Si escribes solo “> 100”, perdiste justo el caso más examinable. Los mark schemes ADORAN esos bordes.
Lucía Navarro
[reflective] Y una última cosa, muy de noche antes del examen. Si ves pseudocódigo y sientes que no entiendes nada, no lo ataques como texto. Reescríbelo mentalmente en Python, aunque sea sin escribir todo. ¿Dónde va el colon? ¿Qué se indenta? ¿Qué variable cambia? Esa mini-traducción te obliga a entender la lógica de verdad.
Diego Salazar
[calm] Sí. Porque al final, programar en examen no es recitar un idioma; es ver la forma del problema. Si puedes ver el bloque, casi siempre puedes escribir la respuesta.