A priori, ça ressemble à un langage de template. Là où ça diffère, c’est que cog ne cherche pas à générer un fichier différent, il insère le code généré dans le fichier original, et garde le code de génération.

Exemple, vous avez envie d’insérer un warning en haut de plusieurs fichiers de code. Vos choix :

• Copier-coller le warning.
• Créer un script de build qui insère le warning.

L’alternative des bricoleurs qui ont juste besoin de quelques insertions, c’est Cog. Par exemple, votre fichier contient :

# [[[cog for l in open('warning.txt'): cog.out("# " + l) ]]]
# [[[end]]]
 
import vostrucs
 
vostrucs.faire_vos_machins()

Après un cog.py -r votre_fichier.py, votre fichier sera :

# [[[cog for l in open('warning.txt'): cog.out("# " + l) ]]]
# Attention, ceci est un avertissmement super important.
# Ce logiciel ne vient avec aucune garantie. Il vomira dans votre salon.
# Violera votre femme, lui collera l'hépatite C et offrira un CD de one direction
# à vos enfants.
# [[[end]]]
 
import vostrucs
 
vostrucs.faire_vos_machins()

cog vient avec plusieurs options, par exemple la possibilité de retirer le code de génération ou de lire le précédent texte généré depuis le code de génération.

La véritable force de l’outil c’est qu’il peut utiliser n’importe quel module Python, et donc générer du texte à partir d’un contenu en ligne ou un fichier CSV. Il est d’ailleurs né parce que l’auteur était codeur C et avait besoin de générer du code à partir d’un fichier XML.

Le seul défaut de Cog, c’est que c’est verbeux. Et moche.

Voici donc un nouveau morceau qui montre comment écrire une petite app de base avec un template et une vue réutilisables qui serviront donc dans les prochaines apps du projet.

Comme d’hab, vous pouvez récupérer le code sur la teub de Guy et il y a une version française et anglaise.

La réponse : utiliser le tag “verbatim” :

{% verbatim %}
  Mettre ici le code que django doit afficher tel quel, sans interpréter.
{% endverbatim %}