4.4 L'âme de Python face à PHP : Flux, Décorateurs et Générateurs

2. Le secret du yield : le marque-page

Pour comprendre ce que yield change vraiment, partons du problème. Sans générateur, la façon naïve de lire un fichier charge tout en mémoire d'un coup :

def lire_tout(fichier: str) -> list:
    with open(fichier) as f:
        return list(f)   # list() force le chargement complet — tout en RAM immédiatement

En Python moderne, for line in f: est déjà lazy par défaut — un fichier ouvert est un itérateur natif, il lit une ligne à la fois. list(f) est la façon explicite de forcer le chargement complet, ce qu'on fait ici uniquement pour montrer le contraste.

Avec yield, on exploite cette nature lazy et on la propage à la fonction entière :

def lire_flux(fichier: str):
    with open(fichier) as f:
        for ligne in f:
            yield ligne.strip()   # ← Python s'arrête ici, rend la valeur, et attend
            #                         au prochain next(), il reprend exactement ici

Ce "freeze" repose sur ce qu'on appelle un Stack Frame. Quand Python suspend une fonction générateur, il conserve en mémoire :

• La position exacte dans le code (à quelle ligne on s'est arrêté)
• Les variables locales à cet instant (ligne, f, etc.)
• Le contexte d'exécution complet

C'est le marque-page : le livre reste ouvert à la bonne page. En pratique, pour un fichier de 10 millions de lignes :

## Approche liste — 10M de lignes chargées en RAM avant le premier print
lignes = lire_tout("access.log")       # peut saturer la mémoire
for l in lignes: print(l)

## Approche générateur — 1 seule ligne en RAM à la fois
for l in lire_flux("access.log"): print(l)   # même résultat, ~0 RAM supplémentaire

Approche liste     → RAM : taille_fichier × taille_moyenne_ligne
Approche générateur → RAM : taille_d_une_ligne + overhead_stack_frame (≈ quelques Ko)

Maintenant que le mécanisme est clair : PHP a yield depuis PHP 5.5 et peut faire la même chose. Voilà l'équivalent PHP :

// PHP — approche naturelle : tout en mémoire
function lireFichier(string $chemin): array {
    return file($chemin, FILE_IGNORE_NEW_LINES);
}

// PHP peut aussi faire du lazy avec SplFileObject — mais c'est moins idiomatique
function lireFlux(string $chemin): Generator {
    $f = new SplFileObject($chemin);
    while (!$f->eof()) {
        yield $f->fgets();
    }
}

La différence : en PHP, lireFlux est une curiosité qu'on sort pour les gros fichiers. En Python, lire_flux est la façon normale de faire. Ce n'est pas une question de syntaxe — c'est une question de culture.

3. L'écosystème lazy : emballer et différer

Les décorateurs et les générateurs ne sont pas deux features indépendantes — ils incarnent la même philosophie. Les deux répondent à : comment éviter de faire plus que nécessaire ?

Les décorateurs : emballer plutôt que dupliquer

Sans décorateur, le même code transversal se répète dans chaque fonction :

# Sans décorateur — répétition, fragile, non-DRY
def parse_pip(raw: str):
    debut = time.perf_counter()
    # ... logique ...
    print(f"parse_pip : {time.perf_counter() - debut:.4f}s")

def parse_gomod(raw: str):
    debut = time.perf_counter()
    # ... logique ...
    print(f"parse_gomod : {time.perf_counter() - debut:.4f}s")

# Avec décorateur — emballé une fois, appliqué partout
@timer
def parse_pip(raw: str): ...

@timer
def parse_gomod(raw: str): ...

Le décorateur enveloppe un comportement transversal (logging, timing, retry, cache) sans polluer la logique métier. C'est l'approche Python du principe DRY.

Les générateurs : différer plutôt que précalculer

# Eager — tout calculé maintenant, même si on n'utilise que le premier
carres = [x**2 for x in range(1_000_000)]   # 1M éléments en RAM
premier = carres[0]

# Lazy — rien n'est calculé tant qu'on n'y touche pas
carres = (x**2 for x in range(1_000_000))   # 0 calcul fait
premier = next(carres)                       # 1 seul calcul effectué

Les deux outils poussent dans la même direction : ne faire que ce qui est nécessaire, au moment où c'est nécessaire.

4. L'analogie du pipeline — décorateurs et générateurs ensemble

Imagine une chaîne de montage : chaque ouvrier reçoit une pièce, la transforme, la passe au suivant — sans attendre que toutes les pièces soient fabriquées. C'est ce que font des générateurs chaînés. Et c'est là qu'on voit les deux outils travailler ensemble.

import re
from utils.decorators import timer

def lire_lignes(fichier: str):
    """Étape 1 — source : lit une ligne à la fois."""
    with open(fichier) as f:
        yield from f   # délègue à l'itérateur natif du fichier

def filtrer_entetes(lignes):
    """Étape 2 — filtre : ignore les lignes d'en-tête."""
    for ligne in lignes:
        if not ligne.startswith('#') and ligne.strip():
            yield ligne

def extraire_composants(lignes):
    """Étape 3 — transformation : parse chaque ligne."""
    for ligne in lignes:
        match = re.search(r"(\S+)\s+([\d\.]+)", ligne)
        if match:
            yield match.group(1), match.group(2)

# @timer + pipeline : le décorateur mesure le temps total car list()
# force l'exécution complète de tous les générateurs d'un coup
@timer
def traiter_fichier(fichier: str) -> list:
    lignes     = lire_lignes(fichier)
    filtrees   = filtrer_entetes(lignes)
    composants = extraire_composants(filtrees)
    return list(composants)   # ← c'est ici que les générateurs s'exécutent vraiment

composants = traiter_fichier("scanner.txt")
# [timer] traiter_fichier    0.0012s
for nom, version in composants:
    print(f"{nom} → {version}")

Le @timer enveloppe la fonction qui consomme le pipeline — il mesure le temps total d'exécution parce que list() force les générateurs à s'exécuter jusqu'au bout. Décorateurs et générateurs se complètent : les uns enveloppent le comportement, les autres diffèrent le calcul.

list() demande une valeur à extraire_composants
  ↓ extraire_composants demande une ligne à filtrer_entetes
    ↓ filtrer_entetes demande une ligne à lire_lignes
      ↓ lire_lignes lit 1 ligne du fichier → remonte dans la chaîne
    ↑ filtrer_entetes filtre → remonte si ok
  ↑ extraire_composants parse → yield (nom, version)
↑ list() reçoit (nom, version) → recommence

En Python, on ne cherche pas à stocker la donnée — on cherche à la faire circuler. Mais circuler avec rigueur.

Pour pyCycloneFlow, c'est exactement ce modèle : lire un fichier de scan, filtrer, parser, produire un SBOM — sans jamais charger l'ensemble en mémoire. La donnée circule, se transforme, et sort en JSON conforme CycloneDX.