organisation projet python et comment coder les fonctions annexes

bonjour
j'ai un projet python qui tourne mais je pense pas bien niveau niveau orga
voila mon dossier
Pièce jointe 664765

En gros j'extrait des trucs dans un dossier source.
Je fais pleins de manips et mon resu final et dans le dossier target
les manips se font enplein d'étapes et je savegarde les resus intermediares dan le dossier temp


J'ai le fichier main qui fait tout ca et il appelle diverses fonctions pour faire mes trucs
Mais je sais pas comment organiser ces fonctions
Au debut j'avais juste un dossier utils avec le fichier helpers et toutes mes focntions dedans.
Mais ca devenait trop gros, alors j'ai gardé dedans que des trucs tres genériques que je peux utiliser ailleurs: des manips sur les dossiers et fichiers

Puis j'ai créé un dossier all_functions pour mettre toutes les fonctins prorpre à mon projet
Dedans, j'ai aussi séparé toutes les fonctions en lien avec l'extract de la source etle reste avec en lien avec le dossier temp et target
est-ce que c'est trop?

car en faisant ca, dans tout ce qui est en lien avec la source, c'est assez simple:
J'ai mes actions d'extrac principales codées dans main extract et qui appelle des focntions specifiques dans le dossier utils_etracts

Le vrai main dans le dossier app appelle alors le le main_extract qui appelle les fonctions dans utils_extract


C'est dans les manips our mettre dans target où ce complique/j'ia psin de fonctins qu'on peut regrouper en 4 types:

J'ai donc un fichier pricnicpe de manip (main_transfo) qui appelle plein de fonctions. les manip de bases sont codés dans 4 fichiers selon leur type.
Et j'ai un fichier helpers qui fait l'intermédiaire: en gros mon main_transfo appelle le fichier helper qui appelle les fonctions dans les 4 fichiers

Est-ce que c'est trop compliqué et comment faire plus simple?

Je précise que mes fonctions élémentaires pour les manips peuvent évoluer. et peut eter qu'un jour j'en aurai 6 types diférents ou alors je voudrais les regrouper en 3 types au lieu de 4 actuellement

Comment vous ferez?

bonjour

- très bien pour le graphique
- mais attention pour le francais ! je pense n'avoir rien compris :oops:

1) Tu ne parles que de fonctions ! donc tu ne fais pas d'objet ? que des fonctions ???
2) Tu ne décris même pas ce que fait ton application donc pas possible de t'aider

puisque pas compris, je peux être a coté de la plaque ...
Tu me semble avoir un niveau de trop (voir 2 ?) :

Code:

---

1 2 3 4 5 6 7 8

main -> utils (?) -> readers (commun.py text.py, html.py, db.py, factures.py ...) en fonction de ton besoin, retourne du "générique" -> writers (commun.py, text.py, sql.py, notification.py ...) en fonction de ton besoin, en entrée du "générique" -> convert : (si possible ???) readers retourne un type générique quel que soit le type en entrée en sortie, même chose, retourne qu'un type générique quel que soit la sortie (traité par writer)

---

Existe aucune loi !
Si l'app doit fortement évoluée (ton cas) , il faut surtout penser à "générique" et surtout "abstraction", l'arborescence vient alors naturellement et n'est que la conséquence.

Bonjour

Citation:

---

Envoyé par gitnoob

Est-ce que c'est trop compliqué et comment faire plus simple?
Comment vous feriez?

---

Déjà tu sens qu'il faut découper les choses. Il ne te manque que l'expérience pour savoir comment découper.

Généralement un projet se découpe en 3 grands domaines

• le modèle, qui sert à stocker les données
• la vue, qui sert à la saisie et à l'affichage des données
• le contrôleur, qui sert à traiter les données

En associant des fonctions à chaque domaine, tu peux mieux gérer et moduler ton projet.

merci meme si j'ai pas tout compris
Je fais pas une appli web ou n truc avec interface graphiqe, juste un cloqe bouton pour faire de taches ennuyantes.

j'ai un dossier sources avec des fichiers txt, xls, json, csv
je veux lire et prednre ce qui m'interesse et les re combiner à ma guise, le résu sera dans target

Je sais pas pas trop ce que je peux dire de plus

C'est quoi le modele, la vue le controleur?


-> utils (?)
-> readers (commun.py text.py, html.py, db.py, factures.py ...) en fonction de ton besoin, retourne du "générique"
-> writers (commun.py, text.py, sql.py, notification.py ...) en fonction de ton besoin, en entrée du "générique"
-> convert
c'est quoi? des dossiers?

Citation:

---

Envoyé par gitnoob

j'ai un dossier sources avec des fichiers txt, xls, json, csv
je veux lire et prednre ce qui m'interesse et les re combiner à ma guise, le résu sera dans target

---

Quelque part, il faudrait transformer les données sous la forme txt, xls, json ou csv en un format "canonique" ou "générique" (plus ou moins indépendantes du format de départ) qui permettra de récupérer (facilement) les unités d'informations recherchées.

Par exemple, une adresse peut être récupérée dans un fichier txt ou xls ou... à la sortie on aura un objet "adresse" avec ses champs remplis indépendamment de leur source. Si on doit chercher je ne sais quoi dans ces objets là, on n'aura plus à se soucier du format de départ.

- W

Hello,

Ta structure actuelle semble déjà bien pensée en termes de séparation des responsabilités, mais elle pourrait être simplifiée ou améliorée en fonction de plusieurs critères.

En ce qui concerne la compréhension de la logique des dossiers et des fichiers, cette séparation semble pertinente, car elle t’évite d’avoir un fichier helpers.py énorme. Cependant, est-ce que les frontières entre extract et transform sont toujours claires ?
Y a-t-il des fonctions qui pourraient être utilisées dans les deux et qui nécessitent d’être dupliquées ou mal placées ?

Tu dis que main_extract.py gère l’extraction et appelle des fonctions spécifiques dans utils_extract, cela semble assez logique.
Est-ce que les fichiers dans utils_extract contiennent des fonctions vraiment indépendantes ? Ou bien certaines d’entre elles sont-elles très spécifiques à un type d’extraction précis ?
Si tu vois que ces fonctions sont trop spécifiques, peut-être que utils_extract pourrait être renommé en extract_methods pour être plus explicite.

Le fichier main_transfo.py gère l’ensemble des manipulations. Mais est-il simplement un point d’entrée ou contient-il aussi de la logique métier importante ?

Le fichier helpers.py sert d’intermédiaire entre main_transfo et les 4 fichiers de transformation. Est-ce nécessaire ?
Si helpers.py ne fait que router des appels, tu pourrais peut-être simplifier en faisant directement appeler main_transfo les fichiers de transformation.
Si helpers.py ajoute une logique supplémentaire (validation, prétraitement, sélection dynamique des fonctions à appeler), alors il a du sens.

L’évolutivité des types de transformation. Si demain tu veux passer de 4 types de transformation à 6 ou revenir à 3, il faut que ce soit simple :

• Est-ce que helpers.py contient une logique conditionnelle compliquée pour choisir le bon fichier ?
• Si oui, tu pourrais envisager une approche où les fichiers de transformation s’enregistrent dynamiquement au lieu d’être appelés explicitement.

On pourrait proposer une amélioration

Plutôt que d’avoir un fichier helpers.py intermédiaire, tu pourrais :

• Créer une classe TransformationManager qui détecte et charge dynamiquement les transformations selon un critère défini.
• Utiliser un pattern plugin où chaque fichier de transformation s’enregistre comme un module disponible.

En conclusion

Ta structure actuelle est fonctionnelle, mais la complexité dans transform vient du fait que tu anticipes une évolution du nombre de types de transformation.
Si helpers.py n’est qu’un simple relais, tu peux le supprimer.
Si la gestion du nombre de types de transformation est un vrai sujet, un système dynamique (classe, mapping de modules) pourrait t’aider à évoluer plus facilement sans tout casser.

Citation:

---

Envoyé par fred1599

Hello,

Ta structure actuelle semble déjà bien pensée en termes de séparation des responsabilités, mais elle pourrait être simplifiée ou améliorée en fonction de plusieurs critères.

En ce qui concerne la compréhension de la logique des dossiers et des fichiers, cette séparation semble pertinente, car elle t’évite d’avoir un fichier helpers.py énorme. Cependant, est-ce que les frontières entre extract et transform sont toujours claires ?
Y a-t-il des fonctions qui pourraient être utilisées dans les deux et qui nécessitent d’être dupliquées ou mal placées ?

Tu dis que main_extract.py gère l’extraction et appelle des fonctions spécifiques dans utils_extract, cela semble assez logique.
Est-ce que les fichiers dans utils_extract contiennent des fonctions vraiment indépendantes ? Ou bien certaines d’entre elles sont-elles très spécifiques à un type d’extraction précis ?
Si tu vois que ces fonctions sont trop spécifiques, peut-être que utils_extract pourrait être renommé en extract_methods pour être plus explicite.

Le fichier main_transfo.py gère l’ensemble des manipulations. Mais est-il simplement un point d’entrée ou contient-il aussi de la logique métier importante ?

Le fichier helpers.py sert d’intermédiaire entre main_transfo et les 4 fichiers de transformation. Est-ce nécessaire ?
Si helpers.py ne fait que router des appels, tu pourrais peut-être simplifier en faisant directement appeler main_transfo les fichiers de transformation.
Si helpers.py ajoute une logique supplémentaire (validation, prétraitement, sélection dynamique des fonctions à appeler), alors il a du sens.

L’évolutivité des types de transformation. Si demain tu veux passer de 4 types de transformation à 6 ou revenir à 3, il faut que ce soit simple :

• Est-ce que helpers.py contient une logique conditionnelle compliquée pour choisir le bon fichier ?
• Si oui, tu pourrais envisager une approche où les fichiers de transformation s’enregistrent dynamiquement au lieu d’être appelés explicitement.

On pourrait proposer une amélioration

Plutôt que d’avoir un fichier helpers.py intermédiaire, tu pourrais :

• Créer une classe TransformationManager qui détecte et charge dynamiquement les transformations selon un critère défini.
• Utiliser un pattern plugin où chaque fichier de transformation s’enregistre comme un module disponible.

En conclusion

Ta structure actuelle est fonctionnelle, mais la complexité dans transform vient du fait que tu anticipes une évolution du nombre de types de transformation.
Si helpers.py n’est qu’un simple relais, tu peux le supprimer.
Si la gestion du nombre de types de transformation est un vrai sujet, un système dynamique (classe, mapping de modules) pourrait t’aider à évoluer plus facilement sans tout casser.

---

Je vais relire tes reponses car j'ai pas tout compris, mais merci

N'hésite pas à poser tes questions !