Au temps pour moi, j'étais pas au courant pour sphinx, mea culpa. Merci beaucoup pour l'info.
Le souci avec les modules c'est déjà le init.py qui est un mécanisme franchement artisanal pour gérer la visibilité du contenu d'un module. Ça a le mérite d'être simple et clair, mais c'est pénible quand ton module commence à être complexe. Franchement, je préfèrerais mille fois avoir un mot clé public, private, protected ou n'importe quoi d'autre pour dire qu'une classe est accessible de l'extérieur. Au moins, ça donne une notion de visibilité du contenu du module, qui n'existe pas en ecmascript/javascript par exemple.
J'ai remarqué qu'en plus, à cause de ça, pour pouvoir mocker des classes ou fonctions importées, on est obligé de dupliquer les imports.
ex concret, avec du vrai code :
Tout ça pour pouvoir faire librement des @patch sur les dépendances. Ça reste moins moisi que les libs de mock en javascript, mais moins élégant que ce qu'on peut voir en groovy.
L'autre point dont j'étais pas fan mais qui a été amélioré, c'est pour importer des modules qui sont dans d'autres dossiers d'une arbo.
ex :
---- CWD
|
|-- lib
| |
| |--- a
| | |-- toto.py -> class Hello
| | |-- titi.py -> class Hella
| |
| |--- b
| |-- tata.py -> class Helluva
|-- ext
|--- c
| |-- yuyu.py -> class Bonjour
La question est donc comment faire pour que toto.py référence de manière propre et modulaire les classes Hella, Helluva et Bonjour.
Ce qui est considéré comme la bonne pratique dans plein de langages c'est les formes suivante :
- pas besoin d'import pour Hella (ce qui ne marche pas en python) ou au pire une notation abrégée
from titi import Hella
pour tous les autres, on considère souvent comme bonne pratique :
from lib.b import Helluva
from ext.c import Bonjour
Alors oui, c'est possible depuis peu en python3. Le souci, c'est que quand on regarde les docs officielles sur les modules,
c'est un vrai défi de trouver quel est l'état de l'art, quelles sont les bonnes pratiques. Il m'a quand même fallu un paquet d'heures pour trouver comment importer proprement des modules. Je suis surtout tomber sur des réponses qui ressemblent à ça et qui donnent envie de se fracasser la tête contre les murs. Donc il n'y a plus trop de souci dans le langage, le problèmeest plutôt la qualité de la doc et des exemples de codes qui ne sont pas à jour. J'ai eu aussi l'impression qu'un pan de la communauté python n'est pas encore consciente de toutes ces nouveautés merveilleuses. Y aurait-il un manque de pub et de marketing sur les nouvelles versions du langage ?
Pour finir, je pensais aussi critiquer le concept du PYTHONPATH, mais au final je n'ai aucun bon argument et c'est comme dans tous les autres langages du monde. Je n'ai donc aucune bonne raison de critiquer ça vu qu'il est difficile de proposer mieux.
[^] # Re: Langage sympa, mais pas fait pour être maintenable
Posté par damaki . En réponse au message De la conception du langage Python. Évalué à 2. Dernière modification le 09 février 2018 à 12:59.
Au temps pour moi, j'étais pas au courant pour sphinx, mea culpa. Merci beaucoup pour l'info.
Le souci avec les modules c'est déjà le init.py qui est un mécanisme franchement artisanal pour gérer la visibilité du contenu d'un module. Ça a le mérite d'être simple et clair, mais c'est pénible quand ton module commence à être complexe. Franchement, je préfèrerais mille fois avoir un mot clé public, private, protected ou n'importe quoi d'autre pour dire qu'une classe est accessible de l'extérieur. Au moins, ça donne une notion de visibilité du contenu du module, qui n'existe pas en ecmascript/javascript par exemple.
J'ai remarqué qu'en plus, à cause de ça, pour pouvoir mocker des classes ou fonctions importées, on est obligé de dupliquer les imports.
ex concret, avec du vrai code :
Tout ça pour pouvoir faire librement des @patch sur les dépendances. Ça reste moins moisi que les libs de mock en javascript, mais moins élégant que ce qu'on peut voir en groovy.
L'autre point dont j'étais pas fan mais qui a été amélioré, c'est pour importer des modules qui sont dans d'autres dossiers d'une arbo.
ex :
La question est donc comment faire pour que toto.py référence de manière propre et modulaire les classes Hella, Helluva et Bonjour.
Ce qui est considéré comme la bonne pratique dans plein de langages c'est les formes suivante :
- pas besoin d'import pour Hella (ce qui ne marche pas en python) ou au pire une notation abrégée
Alors oui, c'est possible depuis peu en python3. Le souci, c'est que quand on regarde les docs officielles sur les modules,
c'est un vrai défi de trouver quel est l'état de l'art, quelles sont les bonnes pratiques. Il m'a quand même fallu un paquet d'heures pour trouver comment importer proprement des modules. Je suis surtout tomber sur des réponses qui ressemblent à ça et qui donnent envie de se fracasser la tête contre les murs. Donc il n'y a plus trop de souci dans le langage, le problèmeest plutôt la qualité de la doc et des exemples de codes qui ne sont pas à jour. J'ai eu aussi l'impression qu'un pan de la communauté python n'est pas encore consciente de toutes ces nouveautés merveilleuses. Y aurait-il un manque de pub et de marketing sur les nouvelles versions du langage ?
Pour finir, je pensais aussi critiquer le concept du PYTHONPATH, mais au final je n'ai aucun bon argument et c'est comme dans tous les autres langages du monde. Je n'ai donc aucune bonne raison de critiquer ça vu qu'il est difficile de proposer mieux.