Modifie le comportement de fold / alphanumerize pour se rapprocher de celui de Grist

Le problème

Aujourd'hui, insitu ne fait pas la différence entre une colonne appelée Commune et une colonne appelée Commune(*) dans la donnée source. C'est un souci car on rencontre souvent des colonnes de ce type dans les données issues du requeteur de Chorus (le logiciel de facturation de l'Etat). Par exemple, les fichiers reçus de l'ANAH dans la contexte des PVD présentent tous ce cas de figure.

Au dernier trimestre, on avait modifié tous les fichiers source à la main pour supprimer la colonne Commune et ne garder que l'autre. On pourrait aussi demander à l'ANAH de supprimer ces colonnes de leurs exports mais potentiellement ça veut dire leur imposer un travail manuel juste pour nous l'épargner.

Ma solution

Le comportement de Grist pour créer des id de colonne propres à partir de nom de colonnes potentiellement pleines de caractères spéciaux est selon moi plus robuste. Elle consiste à remplacer les caractères qui ne sont pas dans [A-Za-z1-9_] par des _ (au maximum un en bout de chaine de caractères, et aucun en début de chaine).

Implémentation

• J'ai modifié le comportement de alphanumerize (et donc de fold) pour reproduire celui de Grist
• J'ai mis à jour les tests associés
• fold est aussi utilisé par les validateurs parse_true et parse_false, et j'ai découvert un peu par hasard que les anciens tests ne passaient que par chance car on leur passait des strings au lieu de leur passer des listes. J'ai corrigé ces tests.

WDYT ?