CR3-S01 · Del bloque al código · Learn

Back to your course / CR3-S01

Computing and Robotics · 3.º ESO · Learn

From blocks to code

The same solution can be expressed with blocks or text. You will follow data, recognise structures and check whether Scratch and Python make the intended decisions.

9 planned lessonsCR3-S01
Understand the idea. Design, test and explain your solution.

Your mission

In pairs, design a classroom monitor with five queries per run and build it in Scratch and Python. Use invented measurements, state their scale or unit and compare decisions with your design. Practice work belongs in A01 and A02, with no additional assessed submission.

Original illustration of students planning and testing a computing project.
Ilustración original creada para esta situación de aprendizaje · Sintaxis Divergente, 2026.

Read the explanation, study the diagram and try the activity in each section. You can choose another version at any time.

Your tools

Use Google Docs for written explanations and diagrams.net for diagrams. Save the editable file as well as the evidence requested in each task.

1.1. One solution and two languages

Learn · theory and practice

An algorithm describes precise steps for solving a problem. A program expresses those steps in an executable language. Decomposition separates tasks such as receiving a measurement, interpreting it and communicating an alert. Abstraction keeps the information needed and leaves out details that do not affect that decision. Before choosing blocks or writing instructions, we must agree on the input and the result we expect.

Input, processing and output describe the path of information. A measurement needs meaning, a range and a scale or unit: the number 24 could represent different things. In this course we can simulate light from 0 to 100 without physical units; this scale is not lux. Typing a number provides a test input, not a sensor reading. A rule written by a person can already automate a response; it does not imply machine learning. Scratch and Python can preserve the algorithm even when their notation and screens differ.

  1. Meaningful input
  2. Precise rule
  3. Response
Original diagram · Sintaxis Divergente

A worked example

A fictional occupancy counter receives 16 and compares it with a teaching capacity of 20. We need to know that both numbers represent people to interpret the comparison. The sign colour can change without changing that rule. However, replacing “less than” with “less than or equal” changes a decision: it belongs to the algorithm, not the visual design.

A text editor showing an example of Python code.
Un ejemplo de código Python en otro entorno; el programa de la unidad es diferente. Captura de Zhanjack822 / Wikimedia Commons, CC0 1.0; sin cambios.
Micro:bit board with LED display, buttons and connection pins.
Una placa micro:bit; el aspecto puede variar según su versión. Foto de Jodiepedia / Wikimedia Commons, CC BY 2.0; sin cambios.

Your turn

  1. In Google Docs, describe the input, meaning, range, rule and output of a fictional indicator different from the final monitor.
  2. In diagrams.net, draw input, processing and output; export the diagram and insert it in the document.
Pause and check

What can change when moving from Scratch to Python without changing the algorithm?

↑ Back to the index

1.2. Editor, interpreter and file

Learn · theory and practice

The editor lets us write code; the Python interpreter executes instructions; the .py file preserves the program. Thonny combines an editor and console, where results appear and questions are answered. Saving preserves program text, but does not automatically save answers from a previous run. We therefore need to recognise the open file, save it in a working folder and run it again after editing.

In a simple initial sequence, instructions run from top to bottom. print() displays information and receives its data inside parentheses; text is enclosed in quotation marks. Python is case sensitive, so print and Print are different names. The >>> symbol in an interactive session is a console prompt and must not be copied into the file. A comment starts with # outside a string and explains intention or limitations; it does not perform the action described. Later, conditions, loops and calls will change the program’s execution path.

  1. .py file
  2. Interpreter
  3. Console
Original diagram · Sintaxis Divergente

A worked example

A student changes a message in the editor but later opens an old copy from another folder. The console still shows the previous text and Python appears to ignore the change. Before rewriting instructions, check the file location, save it and run that version. The symptom can be explained by the version used, rather than necessarily by its logic.

Your turn

  1. In Thonny, save primer_programa.py inside CR3-S01; write two messages and a comment explaining an intention.
  2. Change one message, save and run; record the file used, prediction and observed output in Google Docs.
Pause and check

What does the file preserve, and what information belongs only to one run?

↑ Back to the index

1.3. Values, types and conversion

Learn · theory and practice

A variable keeps a value under a name so it can be used later or replaced when another input arrives. The name expresses what the value represents in the problem. In nivel = 18, = performs assignment; nivel == 18 asks whether the values are equal. When executing contador = contador + 1, Python first evaluates the right-hand side using the previous value and then assigns the result. This is why an update makes sense even though the same name appears on both sides. Clear names without spaces or an initial digit help us follow these changes.

The type matters as well as the value: int represents integers, float numbers with decimals, str text and bool Boolean values. Operations depend on this distinction. Joining strings containing digits preserves a sequence of characters; adding their numeric values performs a calculation. Since input() returns text, an answer that looks like a number still needs conversion before it can be used as one. float() attempts this step; storing the answer in a variable does not do it automatically.

Conversion and validity therefore answer different questions. In these exercises, the agreed format uses a decimal point and leaves the unit out of the answer. Letters or a decimal comma can prevent conversion. A negative value, however, can convert successfully while falling outside the problem’s permitted range. The basic program assumes valid numbers; recovering from incorrect input remains an explicit extension. This distinction lets us explain each outcome without confusing a formatting problem with a measurement outside the scale.

  1. Text answer
  2. Conversion
  3. Number
  4. Domain check
Original diagram · Sintaxis Divergente

A worked example

A screen requests a fictional distance and receives the text “6.5”. Storing that answer does not yet turn it into a numeric measurement. After float(), we can add another compatible distance. If someone enters “-6.5”, conversion can also succeed, although our distance domain rejects it. Recognising numeric format and accepting its meaning in the problem are different questions.

Curso Python. Sintaxis Básica II Tipos, operadores y variables. Vídeo 4

Published by: pildorasinformaticas · Open on YouTube

Watch in short sections. Connect one explanation with the diagram and try the example in this section. The written theory lets you complete the activity without playing the video.

The video keeps its original spoken language. Use the captions available in the player if they help.

Your turn

  1. In Thonny, create entrada_y_conversion.py and compare joining two strings with adding their conversions; try 12, 12.5, hola and 12,5.
  2. In Google Docs, distinguish conversion result, type and permitted range without hiding observed errors.
Pause and check

Why does successful conversion not guarantee valid input?

↑ Back to the index

1.4. Comparing and choosing a branch

Learn · theory and practice

A condition produces a Boolean result: True or False. The operators <, >, <=, >=, == and != express less than, greater than, inclusion of equality, equality and inequality. A threshold separates behaviours; deciding what happens exactly at it belongs to the design. A strict condition does not include equality. Predict that case before running, because many errors appear only at the boundary.

if and else choose one of two paths. Python puts a colon at the end of the header and uses indentation to delimit its body; we will use four spaces per level. An instruction aligned outside both bodies runs after the decision. Two independent if statements can trigger two responses, whereas if/else expresses exclusive alternatives. As an extension, and requires both conditions, or accepts at least one and not reverses a result. Checking a range with and requires a number first; it does not itself repair a failed text conversion.

  1. Comparison
  2. True or false
  3. Chosen branch
Original diagram · Sintaxis Divergente

A worked example

A game awards a badge when the score is greater than 40. At 40 it is not awarded; at 40.5 it is, if decimals are allowed. A “turn finished” message can always appear by placing it after the decision. If it is indented inside one branch, it appears only on that path: position expresses behaviour, not mere decoration.

Curso Python. Condicionales I. Vídeo 10

Published by: pildorasinformaticas · Open on YouTube

Watch in short sections. Connect one explanation with the diagram and try the example in this section. The written theory lets you complete the activity without playing the video.

The video keeps its original spoken language. Use the captions available in the player if they help.

Your turn

  1. In Scratch and Thonny, represent a practice decision with threshold 40 and predict three cases including equality.
  2. In a copy of condicion.py, move a message inside and outside the if; record in Google Docs which runs change.
Pause and check

What observable difference can replacing < with <= produce?

↑ Back to the index

1.5. Repeating without reusing an old input

Learn · theory and practice

A loop repeats a body of instructions. An iteration is one complete pass. In Python, for turno in range(5) visits 0, 1, 2, 3 and 4: the final bound is excluded and five iterations run. range(1, 6) also has five values but starts at 1. Displaying turno + 1 changes the numbering presented, not the values generated by range.

The position of each instruction determines what repeats. If input() is inside the body, an answer is requested on every iteration; outside, the previous value is reused. The same applies to a condition and a function call. A closing message placed outside the loop appears once. Scratch can express a counted repetition with blocks, although it does not necessarily expose the same counter. Five queries provide a clear endpoint for comparing programs. A continuously observing device also needs decisions about frequency and stopping; replacing five with a huge number is insufficient.

Repeat these instructionsNumber of repeats or a condition
A loop returns to its instructions. Its type determines when it stops.
  1. Iteration starts
  2. New input
  3. Decision
  4. Next iteration
Original diagram · Sintaxis Divergente

A worked example

A practice program asks for three colours for a sequence. If the question is placed before the repetition, only one colour is requested and it is shown three times. The program repeats correctly but does not receive the three intended inputs. Alternating different answers reveals this; always entering “blue” might hide the fault. Test data determine what a test can demonstrate.

Curso Python. Bucles I. For. Vídeo 14

Published by: pildorasinformaticas · Open on YouTube

Watch in short sections. Connect one explanation with the diagram and try the example in this section. The written theory lets you complete the activity without playing the video.

The video keeps its original spoken language. Use the captions available in the player if they help.

Your turn

  1. In Thonny, create repetir.py with three queries inside the loop and a closing message outside; reproduce the structure in Scratch.
  2. Move the query outside in a copy and compare both runs in Google Docs using different inputs.
Pause and check

Why does repeating five times not guarantee obtaining five different measurements?

↑ Back to the index

1.6. Functions and correspondences

Learn · theory and practice

A function groups the instructions for a particular task under a name. This organisation allows the task to be checked separately and used later at different points in the program. Defining the function prepares its body but does not start execution. A call directs execution to those instructions; when they finish, the program continues after the call. Separating definition from calling explains why a program can contain a correctly written function without producing any of the messages we expect from it.

Parameters allow the task to receive data without requiring a different definition for every value. In def mostrar(valor), valor is the name used inside the function: the parameter. In mostrar(17), the argument is the specific value, 17, received by that call. The same definition can handle other calls with different arguments. In the basic monitor, the function communicates the alert corresponding to the received measurement and is called on every loop iteration. This connects the new input, the task and its outcome.

A Scratch custom block with an input expresses an organisation comparable to def and its indented body in Python. There are also correspondences between the green flag and running the file, asking a question and receiving information, variables, conditions and repetition. Comparing behaviour helps preserve the algorithm, although differences in types and some operations prevent automatic translation. Within Python, print() displays information and return passes a result to another part of the program. pass allows a valid body that does not yet perform the intended task; its presence does not establish that the task has been completed.

  1. Argument
  2. Call
  3. Parameter and body
  4. Continuation
Original diagram · Sintaxis Divergente

A worked example

The function mostrar_turno(numero) receives a turn and announces it. Calling it with 2 and then 5 uses the same definition with different arguments. Writing only the definition produces no announcement. This practice isolates the parameter and call before adding decisions: if an alert later fails, fewer mixed responsibilities will make its cause easier to investigate.

Your turn

  1. In Thonny, create funciones.py with a function receiving a turn; in Scratch, create the equivalent custom block with an input.
  2. In Google Docs, map start, input, variable, condition, repetition and call in both languages; identify one syntax difference.
Pause and check

What distinguishes a correct definition from a function that actually runs?

↑ Back to the index

1.7. Tracing and debugging with evidence

Learn · theory and practice

A trace records the actual execution path: input, variable, received parameter, comparison, Boolean result and output. It separates what the code does from what the design says it should do. Prepare a prediction first and then compare it with execution. If they differ, either the program or the prediction may be wrong. Following a complete iteration avoids attributing an output to a previous input.

Debugging investigates a discrepancy and corrects its cause. A syntax error prevents a structure from being interpreted; a runtime error occurs during an operation, such as converting letters; a logic error can finish without warnings while making the wrong decision. The message and indicated line provide clues, although the cause may be earlier. Reproduce the symptom, propose a hypothesis, change one cause and repeat the same test. Then check other previously working cases. Record the sequence, expected and observed results, cause, repair and rerun, not just a screenshot of corrected code.

  1. Reproducible symptom
  2. Hypothesis
  3. Single change
  4. Retest
Original diagram · Sintaxis Divergente

A worked example

A sequence should announce each new number but repeats the first. Before changing the loop, record the value received by the function on each call. If the parameter never changes, investigate where input is updated. If it changes but the message does not, inspect the body. Observing an intermediate point distinguishes two causes producing a similar symptom.

Your turn

  1. In Google Docs, trace three practice inputs with variable, parameter, comparison and message before running them in Thonny.
  2. In a copy of funciones.py, introduce a controlled fault and record a hypothesis, correction and rerun, including a previously working test.
Pause and check

Why might the line indicated by an error not contain its cause?

↑ Back to the index

1.8. Testing equivalence and recognising limits

Learn · theory and practice

A test relates input data to expected results defined by the design. For a boundary, use a value below it, the threshold itself and a value above it; for execution flow, alternate inputs and repeat one. The ends of the permitted range and the threshold check different properties. A decimal examines numeric handling. A nonnumeric input explores a limitation of the basic version and must not be presented as a valid case successfully handled.

Comparing Scratch and Python requires the same data in the same order. Their messages may look different while communicating equivalent decisions. If both agree on an incorrect response, they still violate the design: compare them with the intended rule too. In the project, four complete runs of five inputs combine boundary, decimal and repetition tests. The record preserves two incidents and one verified improvement; introduce controlled faults only in a copy. Passing these cases provides specific evidence without proving that every imaginable input will work.

  1. Design rule
  2. Discriminating cases
  3. Comparable executions
  4. Limited conclusion
Original diagram · Sintaxis Divergente

A worked example

A practice classifier distinguishes values below 40. Testing only 4 and 80 does not distinguish that rule from “less than or equal to 40”. The value 40 does. If both versions mistakenly use the second rule, they will agree. Comparing them with the prediction written before programming reveals the incorrect agreement and prevents confusing consistency with correctness.

Your turn

  1. In Google Docs, design a boundary test and one alternating inputs; explain which fault each could reveal.
  2. In Scratch and Thonny, run both and save expected and observed results plus a conclusion about what the checks establish.
Pause and check

What evidence is missing if you only say both programs produce the same result?

↑ Back to the index

Your project and submissions

A01 · Design the solution

  1. In Google Docs, define the problem, audience and one option: simulated light 0–100 with alert if <30; simulated temperature 0–50 °C with alert if >=28; simulated noise 0–100 with alert if >=70; or an equivalent agreed in class. These are educational rules, not certified limits.
  2. Specify input, range, operator, threshold, two messages and equality; use diagrams.net to show start, five queries, a parameterised function and closing.
  3. Map input, variable, condition, loop and function between Scratch and Python; include workshop fragments executed in both and compare a trace.
  4. Prepare four runs of five inputs; across them include below, equality, above, decimal and repetition. Manually trace all five queries of one run.
  5. Identify both partners’ contributions, operation and review; save CR3-S01_A01_Apellidos and individually explain a decision.

What to submit

  • Editable document, diagram and correspondence table.
  • Executed Scratch and Python fragments, four predictions and a five-query trace.
  • Contributions and individual explanation within A01.

A02 · Two languages for one solution

  1. Build monitor.sb3 in Scratch and monitor.py in Thonny: clear start, five new measurements, meaningful variable, A01 condition, custom block and parameterised function called on every iteration, five alerts and closing.
  2. Run the four A01 tests in both versions, including 29, 30 and 31 if you choose the light rule; compare with the design and across languages.
  3. Record two incidents with symptom, cause, correction and rerun; if necessary introduce a controlled fault in a copy. Verify one improvement and state a real limitation.
  4. Save and reopen both editable files; collect the record in CR3-S01_A02_Apellidos and submit the folder with A01 and A02 and review access.
  5. Each partner explains input, equality, loop and call and predicts a change of threshold or reading count; this check belongs to A02.

What to submit

  • monitor.sb3 and monitor.py that can be opened and run.
  • Record of four runs per language, two incidents and one verified improvement.
  • Limitation, identifiable contribution and individual demonstration by each partner.

Before you submit

  • Learner self-assessment descriptors: these do not replace the page’s official rubric.
  • I can follow data through input, variable, condition, function and output in both languages.
  • I can explain equality, conversion, indentation and repetition with my own case.
  • I can repeat a test and demonstrate a correction without confusing agreement with meeting the design.

Templates and files

Open the blank A01 or A02 template and make your own copy in Google Docs. Keep the editable file from your project platform as well.

These reusable templates help you organise your work. Follow the specific instructions and evidence list for this unit; remove fields that do not apply. The blank master is read-only. Keep your answers private and share them only as your teacher instructs.

A01 · Design the solution

  • Editable document, diagram and correspondence table.
  • Executed Scratch and Python fragments, four predictions and a five-query trace.
  • Contributions and individual explanation within A01.

A02 · Two languages for one solution

  • monitor.sb3 and monitor.py that can be opened and run.
  • Record of four runs per language, two incidents and one verified improvement.
  • Limitation, identifiable contribution and individual demonstration by each partner.

Classroom rubrics

The classroom assessment reference is preserved below in its original Spanish. Use the checklist above to prepare your work and ask your teacher about any descriptor you need to clarify.

Consultar la rúbrica de A01

Diseño y microprueba

CYR.3.1.3 Estructuras equivalentes en bloques y Python

Entender cómo funciona un programa informático, la manera de elaborarlo y sus principales componentes.

Evidencia. Algoritmo, correspondencia, traza y fragmentos ejecutados en Scratch y Python de los talleres.

BandaDesempeño observable
1–2,9Confunde asignación y comparación o no puede seguir el fragmento en ninguno de los lenguajes.
3–4,9Reconoce condición y bucle, pero la traza no corresponde al dato o no distingue texto y número.
5–6,9Relaciona variable, dato, operador, condición, bucle y función entre bloques y Python. Ejecuta un fragmento en cada entorno y contrasta su traza.
7–8,9Explica una diferencia de sintaxis y corrige un error de tipo o estructura usando la salida observada.
9–10,0Predice un caso nuevo de frontera y justifica equivalencia funcional sin suponer traducción literal entre lenguajes.

CYR.3.2.1 Solución general, contraste y colaboración

Conocer y resolver la variedad de problemas posibles, desarrollando un programa informático y generalizando las soluciones, tanto de forma individual como trabajando en equipo, colaborando y comunicándose de forma adecuada.

Evidencia. Reto, tabla de seguimiento, cuatro predicciones, microejecución y aportaciones.

BandaDesempeño observable
1–2,9El algoritmo no responde al reto y no puede explicar una decisión propia.
3–4,9Define entradas y salidas, pero no generaliza o las pruebas no distinguen las ramas.
5–6,9Formula el problema, ejecuta una primera solución, anticipa cuatro casos y explica cómo se coordinan sus aportaciones y revisión con la pareja.
7–8,9Revisa el algoritmo por una discrepancia y justifica qué parte sirve para más de una medida o contexto.
9–10,0Compara dos procedimientos y diseña un caso nuevo que permita elegir entre ellos con razones comunicadas al equipo.
Consultar la rúbrica de A02

Producto pruebas y mejora

CYR.3.1.3 Estructuras equivalentes en bloques y Python

Entender cómo funciona un programa informático, la manera de elaborarlo y sus principales componentes.

Evidencia. Versiones editables, casos de frontera y explicación individual de condición bucle y función.

BandaDesempeño observable
1–2,9Las versiones no representan la regla y no puede localizar las estructuras que producen la salida.
3–4,9Una versión funciona parcialmente, pero discrepan en igualdad, tipo o repetición y no explica por qué.
5–6,9Implementa ambas versiones y explica datos, operadores, condición, bucle y función con resultados coherentes en los casos previstos.
7–8,9Localiza dos errores, distingue sintaxis y lógica y verifica las correcciones con los casos afectados.
9–10,0Adapta una regla o entrada nueva y demuestra equivalencia, justificando qué cambia en sintaxis y qué se conserva en el algoritmo.

CYR.3.2.1 Solución general, contraste y colaboración

Conocer y resolver la variedad de problemas posibles, desarrollando un programa informático y generalizando las soluciones, tanto de forma individual como trabajando en equipo, colaborando y comunicándose de forma adecuada.

Evidencia. Comparación de versiones, pruebas, correcciones y modificación individual.

BandaDesempeño observable
1–2,9No resuelve el reto ni puede modificar o explicar una parte de la solución.
3–4,9Consigue una salida, pero no prueba casos que discriminen reglas ni explica aportaciones individuales.
5–6,9Resuelve el reto en ambos lenguajes, contrasta pruebas y correcciones y demuestra individualmente una decisión y colaboración en el proceso.
7–8,9Generaliza a otro dato o umbral y conserva coherencia entre versiones con una explicación del procedimiento.
9–10,0Resuelve una variante no ensayada, compara alternativas y comunica una estrategia reutilizable sustentada en las pruebas.

Videos, resources and sources

Keep learning

Editorial revision: October 2026.