Je ne sais pas dans quelle mesure cette fonction est appelée à être gardée (on sent qu'elle a été faite pour un test spécifique), mais en imposant ici la classe FrenchLidarDataLogic on "casse" la logique qui a été mise en place avec l'héritage.
Dans l'idéal, je pense qu'il faudrait que la classe soit un paramètre d'entrée de make_toy_dataset_from_test_file, du genre :
make_toy_dataset_from_test_file(cls : LidarDataLogic, prepared_data_dir: str, ...)
Et après, on fait :
data_prepper = cls([appel identique])
Tu as raisons, cette fonction a tout d'abord été développée pour les tests fonctionnels. Dans un second temps elle a été ajouter à loading.py pour permettre un démarrage rapide d'un nouvel utilisateur en utilisant ce jeu de donné test.
Mais ça ne me semble pas idéal, et je pense qu'une meilleure approche serait de déplacer cette fonction dans les tests, et de faire en sorte qu'en lançant les tests ce "toy dataset" ne soit pas crée dans un répertoire temporaire mais au contraire persiste.
Ca s'inscrit dans la logique disant que les tests ont une fonction de documentation du code : ici cela démontre le format des données préparées.
_Originally posted by @MichelDaab in https://github.com/IGNF/lidar-deep-segmentation/pull/14#discussion_r872100683_
Tu as raisons, cette fonction a tout d'abord été développée pour les tests fonctionnels. Dans un second temps elle a été ajouter à loading.py pour permettre un démarrage rapide d'un nouvel utilisateur en utilisant ce jeu de donné test. Mais ça ne me semble pas idéal, et je pense qu'une meilleure approche serait de déplacer cette fonction dans les tests, et de faire en sorte qu'en lançant les tests ce "toy dataset" ne soit pas crée dans un répertoire temporaire mais au contraire persiste. Ca s'inscrit dans la logique disant que les tests ont une fonction de documentation du code : ici cela démontre le format des données préparées.