// guide technique

Convertir du WLangage en Python : méthode, équivalences et pièges

Python est la cible naturelle pour les applications WinDev à forte dimension analytique, les outils de traitement de données, les scripts d'automatisation et les backends web légers. Sa lisibilité et son écosystème (pandas, SQLAlchemy, FastAPI) compensent largement l'absence de typage statique pour ces cas d'usage.

Prérequis : exporter le code en format texte

Avant toute conversion, enregistrez vos projets en format texte dans WinDev (option de compatibilité Git). Vous obtenez des fichiers WLangage lisibles, base idéale pour une conversion assistée par IA. Notre guide complet sur la préparation : migrer depuis WinDev.

Équivalences de base WLangage → Python

Le parcours de données : POUR TOUT → list comprehension

L'idiome WLangage POUR TOUT fichier OÙ condition a deux traductions naturelles en Python : la compréhension de liste pour les transformations simples, et une requête SQLAlchemy / psycopg2 pour tout ce qui vient d'une base.

POUR TOUT Commande
  OÙ DateCmd >= DateDébut
  ET Statut = "Validée"
  Total += Commande.MontantHT
FIN

from sqlalchemy import select, func

total = session.scalar(
    select(func.sum(Commande.montant_ht))
    .where(
        Commande.date_cmd >= date_debut,
        Commande.statut == "Validée"
    )
) or 0.0

Pour un traitement en mémoire sur un jeu de données déjà chargé, la compréhension de liste est l'équivalent direct et idiomatique du POUR TOUT WLangage :

// filtrer et transformer une liste
listeNoms est un tableau de chaînes
POUR TOUT c DE commandes
  SI c.Statut = "Validée" ALORS
    Ajoute(listeNoms, c.Client)
  FIN
FIN

# même chose, idiomatique
noms = [
    c.client
    for c in commandes
    if c.statut == "Validée"
]

Pièges classiques de la conversion WLangage → Python

• L'indentation est syntaxique — en Python, l'indentation délimite les blocs. Une conversion automatique qui ne respecte pas l'indentation produit un programme incorrect ou un IndentationError à l'exécution. C'est le premier point de vérification après toute génération par IA.
• L'indexation à 0 — les tableaux WLangage commencent à 1, les listes Python à 0. Le décalage crée des bugs silencieux sur les accès à la dernière position.
• Typage dynamique : pas de garde-fou à la compilation — WLangage et C# refusent de compiler si vous passez une chaîne à une fonction qui attend un entier. Python ne détectera le problème qu'à l'exécution. Utiliser les annotations de type (def f(x: int) -> str:) et mypy permet de retrouver une partie de cette sécurité.
• Booléens et valeurs falsy — en Python, 0, "", [] et None sont tous falsy. if valeur: peut donc avoir un comportement différent de SI valeur <> "" en WLangage si la valeur vaut 0.
• Variables globales de projet — fréquentes dans les projets WX anciens. En Python, les globals sont accessibles en lecture depuis toute fonction, mais leur modification implicite depuis les fonctions crée des effets de bord difficiles à tracer. Transformer en paramètres ou en attributs de classe.
• Appels d'API Windows — certaines applications WinDev appellent des API système via les DLLProcédure ou les composants ActiveX. En Python, ces appels passent par ctypes ou pywin32, mais la migration est souvent l'occasion de remplacer ces dépendances Windows par des bibliothèques multiplateformes.

Gestion des dates et chaînes : points d'attention

d est une Date = DateSys()
sDate est une chaîne
sDate = DateVersChaine(d,
         "JJ/MM/AAAA")
Milieu("Bonjour", 4, 3)

from datetime import datetime
d = datetime.now()
s_date = d.strftime("%d/%m/%Y")

# Milieu(s, pos, n) → s[pos-1:pos-1+n]
"Bonjour"[3:6]  # "jou"

Les fonctions chaîne WLangage (Milieu, Gauche, Droite, Position) s'indexent à 1 ; les slices Python s'indexent à 0 et la borne droite est exclue. Toutes les conversions de ces fonctions doivent être vérifiées manuellement.