En fait si, c'est plutôt maintenu, mais [par d'autres gens](http://nmag.soton.ac.uk/tf/pycaml.html). Le truc c'est que ce genre de technos c'est toujours galère, et c'est moins flexible qu'un design à plusieurs processus communicants, puisque c'est spécifique à la paire de langages utilisés. Avec la méthode multi-process (que ce soit un pipe, des sockets, RPC etc.) tu peux facilement changer de moteur de coloration syntaxique vers un autre langage sans avoir à toucher au côté Caml, ou inversement réutiliser le programme Python dans une autre implémentation de markup engine. --- Pour détailler un peu un point délicat du choix d'impl. : cette solution avec pipe est ce que asmanur appelle "locale", on l'utilise quand on a sous la main une liste de codes à colorer, et elle s'utilise en lançant un processus python qui gère ces codes. L'avantage, c'est que ça permet de continuer à faire agir mldown comme une boîte noire : on appelle mldown sur chaque fichier .text, et lui de façon invisible pour l'utilisateur utilise ce sous-process python pour colorer toutes les sources d'un .text. L'inconvénient, c'est que le sous-process python est lancé pour chaque .text parsé par mdown. Pour un programme comme TLC qui fait plein d'appels successifs à mldown avec plein de documents différents, le coût de lancement de pygments reste dupliqué pour chaque document. C'est mieux que quand on le payait pour chaque snippet de code, mais c'est moins bien que ce qu'on aurait avec une solution non-locale où on passe à chaque appel mdown une instance globale d'un process python (une sorte de "pygments daemon" quoi). L'intérêt des FIFO c'est qu'elles permettent de faire les deux à la fois, du local et du global. Par contre, il me semble ça utilise les "named FIFOs" qui existent sous Unix, mais pas sous Windows. Une solution basée sur des sockets serait plus portable. Avec l'implémentation ci-dessus, on utilise un pipe, qui à priori n'est une solution que locale, mais qui pourrait peut-être être utilisée globalement (par exemple le process appelé pourrait contacter un serveur/daemon global en lui faisant passer ses descripteurs d'entrée/sortie). Dans tous les cas, la partie du code "interopérabilité des données inter-langages" utilisant JSON est réutilisable.