Taak 3: Een eigen module importeren

In taak 2 heb je je code opgesplitst in kleine helper-functies. Die staan nu nog allemaal in hetzelfde bestand als je hoofdscript. Zodra dat bestand groeit, loop je opnieuw vast:

# monitor.py — helpers en uitvoering door elkaar

def is_valid_temp(temperature):
    return 0 <= temperature <= 100

def format_reading(temperature):
    return f"Temperatuur: {temperature}°C (max: 100°C)"

# ... nog 8 helpers ...

readings = [45, 120, 80]
for temperature in readings:
    if is_valid_temp(temperature):
        print(format_reading(temperature))

Drie concrete problemen

1. Niet herbruikbaar. Een tweede script dat is_valid_temp() nodig heeft, moet de functie kopiëren — precies de duplicatie uit US1.
2. Niet los te testen. Je kunt de helpers niet aanroepen zonder dat het hele script gaat draaien.
3. Onoverzichtelijk. Je scrolt langs tien definities voordat je ziet wat het script eigenlijk doet.

De oplossing: een eigen module

Elk .py-bestand in dezelfde map is een module die je kunt importeren. De bestandsnaam zonder .py is de modulenaam:

# monitor.py
def is_valid_temp(temperature):
    return 0 <= temperature <= 100

def format_reading(temperature):
    return f"Temperatuur: {temperature}°C"

readings = [45, 120, 80]
for temperature in readings:
    ...

# 1 bestand, alles vermengd

# helpers.py — alleen definities
def is_valid_temp(temperature):
    return 0 <= temperature <= 100

def format_reading(temperature):
    return f"Temperatuur: {temperature}°C"

# main.py — alleen uitvoering
from helpers import is_valid_temp
from helpers import format_reading

readings = [45, 120, 80]

De importregel ontleed

from helpers import is_valid_temp, format_reading
#    ^^^^^^^        ^^^^^^^^^^^^^  ^^^^^^^^^^^^^^
#    bestandsnaam   welke namen je wilt gebruiken
#    zonder .py

# Daarna gebruik je ze alsof je ze hier zelf had geschreven:
print(format_reading(45))

Interactieve demo — wat draait er wanneer?

Kies welk bestand je start. Zet de schakelaar aan of uit om te zien wat if __name__ == "__main__": doet:

Een module is niets bijzonders: het is gewoon een .py-bestand. Toch gebeurt er bij het importeren meer dan je op het eerste gezicht denkt, en dat verklaart bijna alle fouten die je in deze taak kunt maken.

Wat gebeurt er precies bij een import?

Python zoekt het bestand, en voert het volledig uit van boven naar beneden. Alle def-regels worden uitgevoerd — dat maakt de functie aan, maar roept hem niet aan. Daarna zijn de namen beschikbaar in het importerende bestand.

Het venijn zit in code die géén definitie is. Die draait namelijk óók, op het moment van importeren:

# sensors.py
print("Sensormodule geladen")     # draait bij ELKE import

def read_temperature():
    return 45

readings = [read_temperature()]   # draait óók bij elke import

# main.py
from sensors import read_temperature
# Uitvoer: Sensormodule geladen
#          ← je hebt niets aangeroepen, en tóch draaide er code

De drie importvormen

Er zijn drie manieren om te importeren. Ze verschillen in hoeveel je binnenhaalt en hoe duidelijk het blijft waar een naam vandaan komt:

# 1. from … import … — de standaardkeuze
from helpers import is_valid_temp, format_reading
print(format_reading(45))

# 2. import … — je houdt de modulenaam ervoor
import helpers
print(helpers.format_reading(45))

# 3. from … import * — importeert alles; gebruik dit niet
from helpers import *
print(format_reading(45))   # waar komt deze functie vandaan?

Vorm 1 is het duidelijkst voor eigen modules: je ziet bovenaan het bestand precies welke namen van buiten komen. Vorm 2 is handig als twee modules dezelfde functienaam hebben — sensors.read() en files.read() botsen dan niet. Vorm 3 maakt onvindbaar waar een naam vandaan komt en kan bestaande namen overschrijven.

De main-guard: __name__

Python zet in elk bestand automatisch de variabele __name__. De waarde hangt af van hoe het bestand draait:

• Start je het bestand zelf (python main.py) → __name__ is "__main__"
• Wordt het geïmporteerd → __name__ is de modulenaam, dus "main"

Daarmee kun je code schrijven die alleen draait bij direct starten. Vergelijk beide varianten:

# ZONDER guard — deze code draait ook bij importeren
readings = load_readings()
for temperature in readings:
    print(format_reading(temperature))


# MET guard — deze code draait alleen bij: python monitor.py
if __name__ == "__main__":
    readings = load_readings()
    for temperature in readings:
        print(format_reading(temperature))

Veelgemaakte fouten

Fout 1: uitvoercode op het hoogste niveau van een module

# ❌ FOUT: helpers.py
def is_valid_temp(temperature):
    return 0 <= temperature <= 100

readings = load_all_sensors()      # draait bij elke import!
print(f"Aantal metingen: {len(readings)}")

# ✅ JUIST: helpers.py bevat alleen definities
def is_valid_temp(temperature):
    return 0 <= temperature <= 100

def load_all_sensors():
    return [45, 80, 12]

Zolang je module alleen definities bevat, kun je hem overal importeren zonder bijwerkingen. Dat is precies wat een testbestand nodig heeft.

Fout 2: circulaire import

# ❌ FOUT
# validation.py
from formatting import format_error      # importeert formatting

# formatting.py
from validation import is_valid_temp     # importeert validation terug
# → ImportError: cannot import name ...

Twee modules die elkaar importeren geven een fout: Python is de eerste module nog aan het laden als de tweede hem al nodig heeft. Los het op met eenrichtingsverkeer — main.py importeert de modules, de modules importeren elkaar niet.

Fout 3: een bestandsnaam die al bestaat

# ❌ Je maakt een bestand random.py in je projectmap
import random
print(random.randint(1, 10))
# → AttributeError: module 'random' has no attribute 'randint'

Python vindt eerst jouw bestand en niet de standaardmodule. Vermijd namen als random.py, math.py, json.py en time.py.

Edge case: een module wordt maar één keer geladen

Importeer je dezelfde module in drie bestanden, dan draait de modulecode toch maar één keer. Python onthoudt geladen modules. Dat is efficiënt, maar het betekent ook dat een globale variabele in een module gedeeld wordt door alles wat hem importeert — weer een reden om er alleen definities in te zetten.

Wanneer wel en niet splitsen?

• Wel: bij meer dan ongeveer 100–150 regels, of zodra een tweede script dezelfde functies nodig heeft.
• Wel: zodra je de logica wilt testen zonder de rest te starten.
• Niet: bij een script van 30 regels dat één ding doet — dan levert een tweede bestand alleen extra gedoe op.
• Niet: één module per functie. Groepeer per onderwerp: validatie bij validatie, opmaak bij opmaak.

Interactieve demo — wat draait er wanneer?

Start beide bestanden met de guard aan en uit. Let vooral op wat er gebeurt bij test_helpers.py zonder guard — dat is de fout die je in de praktijk het vaakst ziet:

Scenario: je vluchtscript uit taak 2 bevat inmiddels acht helper-functies en de opstartcode door elkaar. Je wilt de helpers in een eigen bestand zetten, zodat je hoofdscript alleen nog het vluchtplan uitvoert — en zodat je de helpers kunt testen zonder dat er een drone in de lucht komt.

Gegeven constanten:

VALID_DIRECTIONS = ["forward", "back", "left", "right", "up", "down"]
MIN_DISTANCE = 20
MAX_DISTANCE = 500

Je taak: splits je project in drone_helpers.py en main.py. Bepaal zelf welke functies waar horen en hoe je ze importeert.

Acceptatiecriteria:

• drone_helpers.py bevat alleen definities en constanten — geen code die iets uitvoert
• main.py importeert de helpers met from drone_helpers import ...
• Alle uitvoercode in main.py staat achter if __name__ == "__main__":
• Met de drone vliegt main.py het plan uit taak 2 precies zoals vóór het splitsen
• import drone_helpers in een leeg bestand geeft geen enkele uitvoer

Scenario: nu je helpers in een eigen module staan, kun je ze controleren zonder de drone aan te zetten. Schrijf een derde bestand dat je validatie-helper test met een geldig én een ongeldig vluchtplan.

Hints:

• Importeer alleen de functie die je test — niet de hele module
• Een test bestaat uit: een bekende invoer, de functie aanroepen, en het resultaat vergelijken met wat je verwacht
• Gebruik minstens één plan dat moet slagen en één dat moet falen (te grote afstand of onbekende richting)
• Print aan het eind één regel waaruit blijkt of alles klopte
• Lukt het testbestand niet zonder foutmelding? Dan staat er nog uitvoercode in je module

Acceptatiecriteria:

• Het testbestand draait zonder dat er een drone verbonden is
• Er wordt minstens één geldig en één ongeldig plan gecontroleerd
• De uitvoer laat per test zien of het resultaat klopte met de verwachting