Discussion :

[Pyramidev]

Il est tellement plus simple de tout mettre dans un seul fichier à la racine...
Cela va donner de bonnes bases à ces étudiant qui n'auront du coup plus besoin de faire un seul import.

Il n'y a pas besoin d'aller jusqu'à tout mettre dans le même fichier. Tu peux te contenter de mettre tous les fichiers dans le même dossier et les imports marcheront. En effet, quand on exécute un script Python, le chemin du dossier dans lequel il se trouve est automatiquement mis en tête de sys.path.

C'est à partir du moment où on découpe le code en plusieurs dossiers qu'on a besoin d'apprendre des spécificités de Python sur la gestion des imports. En effet, si on appelle un script A dans un dossier qui importe un module B d'un autre dossier qui lui-même fait un import absolu d'un module C, alors le fait qu'il trouve C ou non dépend de sys.path, qui lui-même dépend de plein de choses.
https://docs.python.org/3/tutorial/m...le-search-path

Remarque : j'ai précisé "import absolu", car il y existe aussi les imports relatifs : https://docs.python.org/3/tutorial/m...age-references

Ok je vois mieux ton souci. Cela vient du fait que ce tutoriel passe par un intermédiaire (PyCharm) qui est apparemment un IDE. Or cet IDE (attention, je ne le connais pas, je ne l'utilise pas, tout ce que je dis n'est qu'une hypothèse par rapport à ce que je lis de ce chapitre 9 et par rapport à ma façon de travailler) ne considère pas le programme exécuté comme étant la racine d'exécution.

Cette hypothèse est fausse. Je viens de faire un test.

Accessoirement P2 acceptait des imports relatifs (à ta position), P3 ne les accepte plus.

Les imports relatifs existent toujours en Python 3.

[Sve@r]

Il n'y a pas besoin d'aller jusqu'à tout mettre dans le même fichier. Tu peux te contenter de mettre tous les fichiers dans le même dossier et les imports marcheront.

A mon avis c'était de l'ironie...

Cette hypothèse est fausse. Je viens de faire un test.

Ok. mais dans ce cas je ne pige pas pourquoi ce tutoriel impose alors de taper dans sys.path comme si c'était une boite de chocolats...

Les imports relatifs existent toujours en Python 3.

Oups...

[wiztricks]

Le tutoriel que vous mentionnez, je l'ai lu, c'est même le premier que j'ai lu.
Alors, je suis sans doute un abruti fini incapable de comprendre des phrases simples parce que je trouve que le peu que ce tutoriel en dit au chapitre 6 n'aide vraiment pas à comprendre à quoi ça sert, ni à quel moment il faut s'en servir.

Essentiellement parce que ce sont des solutions a des problèmes que vous n'avez pas encore: l'organisation d'une application en packages/modules voire des parties communes à plusieurs applications (où là il y aura sans doute des choses en dehors des arborescences de recherche par défaut).

Il faudra relire ce chapitre lorsque le moment sera venu et faire une lecture active i.e. tester voir si ça le fait comme compris pour imaginer comment construire avec les contraintes imposées plutôt que d'essayer de tordre le truc pour qu'il se plie à vos idées.

C'est vrai que j'accorde sans doute trop d'importance à l'organisation du code.
Il est tellement plus simple de tout mettre dans un seul fichier à la racine...

C'est plutôt niais de dire çà alors qu'on parle d'un chapitre de tutos qui parlent de l'organisation du code en packages/modules/...

Ou alors, il y a encore un super tutoriel que tous les débutants sont sensé connaître. Vous devriez en faire une liste et la refiler à l'Education Nationale...

Jusqu'en terminale, le Python raconté par le Swinnen (qui est un apprentissage à la programmation avec Python plus qu'un tour des fonctionnalités du langage) serait déjà pas si mal.

Ce n'est pas la première fois que que je constate que vous prenez les gens de haut en leur disant que "c'est noté dans dans tous les bons tutoriels".

Le savoir est dans la documentation et les tutos... et c'est pour pouvoir le partager qu'on les a écrits.
Après, les individus doivent avoir construit leur grille de lecture pour pouvoir en profiter et en faire des connaissances (être capable d'en faire quelque chose).
Sinon, on lit des phrases sans signification qu'on oubliera vite parce que son cerveau ne saura pas connecter ces bouts avec le reste.

- W

[popo]

Essentiellement parce que ce sont des solutions a des problèmes que vous n'avez pas encore: l'organisation d'une application en packages/modules voire des parties communes à plusieurs applications (où là il y aura sans doute des choses en dehors des arborescences de recherche par défaut).

Il faudra relire ce chapitre lorsque le moment sera venu et faire une lecture active i.e. tester voir si ça le fait comme compris pour imaginer comment construire avec les contraintes imposées plutôt que d'essayer de tordre le truc pour qu'il se plie à vos idées.

Mes idées ?
C'est m'accorder trop d'honneur d'affirmer que je suis le premier à vouloir organiser mes fichiers autrement que de tout mettre dans le même répertoire.

C'est plutôt niais de dire çà alors qu'on parle d'un chapitre de tutos qui parlent de l'organisation du code en packages/modules/...

C'est pesant de constater que vous sortez systématiquement les phrases de leur contexte.
Vous avez affirmé, je cite "Pour enseigner la programmation en utilisant le langage Python, un prof. n'a pas besoin de connaître les subtilités de sys.path ni C ou C++"
En réponse, je fais la remarque (certes en utilisant l'ironie) qu'il n'était pas sain de tout mettre au même endroit (donc sous-entendu qu'il valait mieux créer des modules).
Et là vous me rétorquer que ma remarque est niaise.
Il faudrait voir à ne pas changer d'avis tous les cinq matins.
Soit un prof enseigne à ces élèves à organiser leurs codes et il faut donc qu'il connaisse le sys_path
Soit ce n'est pas nécessaire mais ça signifie que les étudiant ressortent du lycée en pensant que c'une bonne chose de tout mettre au même endroit parce que leur prof ne leur a pas dit qu'il fallait organiser leurs code.

Jusqu'en terminale, le Python raconté par le Swinnen (qui est un apprentissage à la programmation avec Python plus qu'un tour des fonctionnalités du langage) serait déjà pas si mal.

J'ai acheté ce livre.
Et la dernière édition date de 2012.
J'ai pu constaté en lisant d'autres tutos plus récents qu'il y a quelques routines qui ont évolué depuis, notamment la routine print et la méthode format des type str.
Il y a sans doute d'autres choses qui ont bougé depuis.
Dans la section "cours", il y en a une version numérique qui date de 2015 mais qui souffre de problèmes d'indentations (et les chapitres ont été réorganisés ce qui fait que les corrigés à la fin ont des numérotations décalées).
Pas de mention de sys_path à l'intérieur non plus.

[wiztricks]

Et là vous me rétorquer que ma remarque est niaise.

Ben oui: le chapitre qui parle de sys.path (que vous n'avez pas vu) est aussi celui qui parle des modules... donc me faire dire que je recommanderai de tout mettre dans un même module ou répertoire.

Après si vous ne comprenez pas que ce qu'on donne à manger aux professeurs n'est pas la même chose qu'on donne aux programmeurs qui ont déjà touché à d'autres langages qu'au gamin à qui on essaie d'enseigner les rudiments de la programmation...

C'est votre problème (après tout il y a bien 10% de platistes).

J'ai acheté ce livre.
Et la dernière édition date de 2012.
J'ai pu constaté en lisant d'autres tutos plus récents qu'il y a quelques routines qui ont évolué depuis, notamment la routine print et la méthode format des type str.

Ah ben ouais, ça n'est pas mis à jour avec les dernière nouveautés mais ce qu'on y apprend reste d'actualité (ça marche encore) et vu l'audience que cet ouvrage vise, ça me semble acceptable.

- W

[Sve@r]

Soit un prof enseigne à ces élèves à organiser leurs codes et il faut donc qu'il connaisse le sys_path

Euh... encore une fois taper dans sys.path n'est pas une obligation pour organiser son code. Mais je suis d'accord sur le fait qu'un prof doit connaitre tous (enfin autant que possible) les détails de la matière qu'il a à enseigner pour pouvoir répondre aux questions de détail (dans laquelle le chapitre des imports peut alors effectivement faire intervenir sys.path).

[popo]

Ben oui: le chapitre qui parle de sys.path (que vous n'avez pas vu) est aussi celui qui parle des modules... donc me faire dire que je recommanderai de tout mettre dans un même module ou répertoire.

Après si vous ne comprenez pas que ce qu'on donne à manger aux professeurs n'est pas la même chose qu'on donne aux programmeurs qui ont déjà touché à d'autres langages qu'au gamin à qui on essaie d'enseigner les rudiments de la programmation...

C'est votre problème[

.
Je n'ai pas vu ce chapitre selon vous ?
Là c'est carrément de la mauvaise foi puisque que j'ai justement cité ce chapitre dans cette discussion et que vous vous êtes empressé de dire que je ne l'avais pas compris parce que je n'avais pas été confronté à la situation.
Si on est parti sur le sys_path, c'est justement parce que je l'ai mentionné. Et si je l'ai mentionné c'est parce que j'y ai été confronté. Lorsqu'on baigne dans le python toute la journée comme vous, c'est facile de dire que certaines choses sont évidente. Mais lorsqu'on est confronté au problème pour la première fois et qu'on lit ce chapitre, c'est assez maigre comme documentation, ça manque cruellement d'exemples concrets.

Et oui, puisque vous dites vous même que le sys_path va de pair avec la notion de module et que c'est pour ça qu'ils sont abordés dans le même chapitre, alors affirmer qu'un prof n'a pas besoin de se préoccuper de sys_path , c'est affirmer que ce prof n'as pas besoin d'enseigner la notion de modules à ces élèves, et par extension leur faire prendre l'habitude de tout mettre au même endroit.

[wiztricks]

c'est affirmer que ce prof n'as pas besoin d'enseigner la notion de modules à ces élèves, et par extension leur faire prendre l'habitude de tout mettre au même endroit.

C'est une extrapolation dont je vous laisse la responsabilité.

Et si vous n'avez pas compris que sys.path et modules étaient des concepts associés mais différents, on sort des questions techniques (vous ne savez pas de quoi vous parlez).

- W

[marco056]

Bonjour à tous,

Je reprends le fil de la discussion et je m’aperçois que mes propos vis à vis de l’oubli du prof de donner le
«*tutoriel*» de Python ouvre une nouvelle discussion sur la formation des profs.

Tout d’abord ce n’était pas du tout le but de cette phrase. L’idée était qu’avec les bons outils au bon moment le travail est certainement plus facile. Un oubli peut arriver à n’importe qui et je ne jette pas la pierre à son prof.

Ensuite en ce qui concerne les programmes éducatifs, les profs doivent appliquer ce qui descend de la haute sphère éminente qu’est le ministère de l’éducation nationale. On leur demande de faire du python alors ils doivent apprendre à leurs élèves du Python… La volonté des uns et des autres de se former ou pas à un nouveau
«*langage*» est personnelle, mais comment faire apprendre quelque chose à un élève qu’on ne maîtrise pas soit même ???

Pour sve@r, si vous relisez bien l’énoncé de la question 3 le programme doit proposer les nombres à donner pour gagner le plus vite possible. Du coup je me dis que le script de ma fille colle plutôt bien à l’énoncé puisqu’à chaque boucle, la phrase «*je propose «*e*» apparaît, et qui de ce fait répond bien au problème… Je ne vois pas où est la redondance ? D’ailleurs si vous testez le programme donné en début d’exercice a chaque tour python vous demande quel chiffre vous souhaitez proposer, mais dans ce cas il faut l’écrire. Dans son script c’est
«*automatisé*»

Désolé, c'est moi qui ai un peu dévié. J'interviens juste une dernière fois sur ce HS : je voulais juste dire que les profs qui font du python en lycée sont des profs de maths, techno ou physique et n'ont à la base aucune compétence en informatique, d'où leur manque de compétence parfois et même un désintérêt.

[popo]

C'est une extrapolation dont je vous laisse la responsabilité.

Et si vous n'avez pas compris que sys.path et modules étaient des concepts associés mais différents, on sort des questions techniques (vous ne savez pas de quoi vous parlez).

- W

Je veux bien admettre que je n'ai pas la même expérience que vous sur python mais ce que je dis sur le sys.path ne vient pas de moi mais du tutoriel de Serge Tahé qui décrit de manière détaillée les différents cas d'imports de modules et la nécessité dans certains cas d'aller ajouter un chemin dans le sys.path. Vous allez aussi affirmer que Serge Tahé ne sais pas quoi il parle ?

[wiztricks]

ce que je dis sur le sys.path ne vient pas de moi mais du tutoriel de Serge Tahé

L'important sera de ce que vous allez en faire (votre connaissance du sujet).

Je ne pense pas qu'un Serge Tahé Python puisse dire:

affirmer qu'un prof n'a pas besoin de se préoccuper de sys_path , c'est affirmer que ce prof n'as pas besoin d'enseigner la notion de modules à ces élèves, et par extension leur faire prendre l'habitude de tout mettre au même endroit.

Si vous aviez pris le temps de comprendre ce que sont modules et packages, vous sauriez qu'on peut déjà les répartir dans une hiérarchie de répertoires. Ça qui permet déjà de réaliser des projets assez conséquents (allez regarder les sources des grosses bibliothèques, rares sont celles qui ont besoin de modifier le path).

N'oubliez pas que vous êtes dans un forum technique. Si vous dites une ânerie, c'est pas grave. Mais si vous prenez plaisir à vous y vautrer sans arguments techniques et juste de la rhétorique, çà ne sert à rien ni à personne.

- W

[Sve@r]

mais ce que je dis sur le sys.path ne vient pas de moi mais du tutoriel de Serge Tahé qui décrit de manière détaillée les différents cas d'imports de modules et la nécessité dans certains cas d'aller ajouter un chemin dans le sys.path.

Dans "certains cas", comme tu le dis si bien. Donc pas dans tous. Et le "certains" étant plutôt assez rare.

Je viens de télécharger ses exemples et j'ai isolé celui dont tu parles (le dossier "impots"). Son architecture est la suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
racine
|__ impots
    |___ v01
        |___ main.py
        |___ shared
            |___impôts_module_01.py

Or dans le "main.py" il fait un from impots.v01.shared.impôts_module_01 sous-entendant qu'il présume se trouver dans le dossier "racine" quand il lance cet import. Ce qui n'est absolument pas le cas. Comme je te l'ai dit, quand tu exécutes un script, tu pars alors de l'endroit où se trouve le script. Si tu lances "main.py" tu te trouves alors dans "impots/v01". Et de cet endroit, il n'y a aucun fichier nommé "impots/v01/shared/impôts_module_01.py", seulement un fichier nommé "shared/impôts_module_01.py".

De là deux solutions

1. modifier sys.path pour rajouter le chemin "racine" afin que, depuis ce chemin, il puisse trouver le fichier impots/v01/shared/impôts_module_01.py"
2. remplacer cet import par from shared.impôts_module_01 import *

Et de fait, cette seconde solution fonctionne parfaitement (testé)

Vous allez aussi affirmer que Serge Tahé ne sais pas quoi il parle ?

On n'ira pas jusque là. Peut-être a-t-il voulu créer une situation spéciale afin de montrer cette possibilité en négligeant d'expliquer en quoi celle-ci était facultative (ou en quoi elle était nécessaire dans cet exemple spécifique pour telle ou telle raison). Mais ce n'est pas une raison, après avoir affirmé qu'utiliser les modules impose de connaitre sys.path, de surenchérir à l'excès comme tu l'as fait quand on te dit "pas nécessairement" pour en arriver à ta conclusion récente que ne pas se préoccuper de sys.path équivaut à ne pas enseigner les modules.

[popo]

L'important sera de ce que vous allez en faire (votre connaissance du sujet).

Je ne pense pas qu'un Serge Tahé Python puisse dire:
*ne pense pas qu'un Serge Tahé Python puisse dire:
*Envoyé par*popo*:
affirmer qu'un prof n'a pas besoin de se préoccuper de sys_path , c'est affirmer que ce prof n'as pas besoin d'enseigner la notion de modules à ces élèves, et par extension leur faire prendre l'habitude de tout mettre au même endroit.

.
Encore une fois vous prenez des phrases que vous sortez de leur contexte Je n'ai jamais prétendu que Serge Tahé puisse dire ça C'est tout le contraire, j'ai pris Serge Tahé comme exemple pour dire qu-il a démontré par l'exemple l'importance de sys.path.

Si vous aviez pris le temps de comprendre ce que sont modules et packages, vous sauriez qu'on peut déjà les répartir dans une hiérarchie de répertoires. Ça qui permet déjà de réaliser des projets assez conséquents (allez regarder les sources des grosses bibliothèques, rares sont celles qui ont besoin de modifier le path).}

Sqlalchemy, c'est assez conséquent ?
Alors, cartes ils ne vont pas modifier le sys_path mais ils remontent souvent dans la hiérarchie des répertoires avec ".." (dans les __init__ notamment ), pour obtenir le même résultat.

N'oubliez pas que vous êtes dans un forum technique. Si vous dites une ânerie, c'est pas grave. Mais si vous prenez plaisir à vous y vautrer sans arguments techniques et juste de la rhétorique, çà ne sert à rien ni à personne.

C'est justement parce qu'on est dans un forum technique et parce que la notion de sys_path est assez mportante pour être dans les premiers chapitres de la documentation officielle ou pour être le sujet d'un chapitre complet dans le tutoriel d'une personne reconnue compétente, que je tique quand vous affirmez que ce n'est qu'un détail qu'un prof n'a pas besoin de connaître.

Je viens de*télécharger ses exemples*et j'ai isolé celui dont tu parles (le dossier "impots"). Son architecture est la suivante

racine |__ impots |___ v01 |___ main.py |___ shared |___impôts_module_01.py

Je ne parle pas de ce chapitre mais du 9.4 avec un fichier module1.py dans un répertoire dir1 et un fichier module2.py dans un répertoire dir2 faisant un import de module1 et où, on se retrouve avec une erreur
ModuleNotFoundError
Dans le chapitre 9.5, Serge Tahé résoud ce problème en ajoutant "." et "./dir1" dans le SYS_PATH.
Dans le chapitre 9.6, il crée carrément une routine pour le faire.
Cette routine il la met ensuite dans un packages myutils qu'il installe dans l'environnement et tout les autres chapitres ont des config.py qui s'appuient sur la routine crée au chapitre 9.6

On n'ira pas jusque là. Peut-être a-t-il voulu créer une situation spéciale afin de montrer cette possibilité en négligeant d'expliquer en quoi celle-ci était facultative (ou en quoi elle était nécessaire dans cet exemple spécifique pour telle ou telle raison). Mais ce n'est pas une raison, après avoir affirmé qu'utiliser les modules impose de connaitre sys.path, de surenchérir à l'excès comme tu l'as fait quand on te dit "pas nécessairement" pour en arriver à ta conclusion récente que ne pas se préoccuper de sys.path équivaut à ne pas enseigner les modules

Je veux bien admettre que je suis parti loin dans la surenchère.
Mais il n'empêche que même s'il existe des automatismes inclus nativement ou des syntaxes avec ".." pour ne pas avoir à toucher au sys.path, il faut que le chemin vers un module soit connu au moment de l'exécution sinon on se retrouve avec une erreur ModuleNotFoundError.

Bref, j'ai peu être un peu exagéré les choses mais un prof est sensé donner des bases solides à ces étudiant et j'estime que ne pas leur parler de la notion de sys_path (même s'ils n'ont pas à s'en soucier la plupart du temps), ce n'est pas leur rendre service.

Si les concepteurs de python eux même ont estimé la notion de sys_path suffisamment importante pour être incluse dans la documentation officielle, je trouve bien prétentieux de la part de wiztricks, d'affirmer que cette notion n'a pas besoin d'être connue par quelqu'un qui est chargé d'enseigner python.

[Sve@r]

Si les concepteurs de python eux même ont estimé la notion de sys_path suffisamment importante pour être incluse dans la documentation officielle, je trouve bien prétentieux de la part de wiztricks, d'affirmer que cette notion n'a pas besoin d'être connue par quelqu'un qui est chargé d'enseigner python.

Une documentation officielle n'est pas un tutoriel d'apprentissage.
L'apprentissage (et ceci pour toute matière) se fait par étapes successives. Toutefois (et c'est là un point important), chaque étape complète certaines erreurs ou omissions de l'étape précédente, erreurs ou omissions dues à la simplification de ladite étape. Mais simplifications obligatoires pour faciliter la compréhension.
Prend le petit enfant qui regarde le soleil, on commence par lui expliquer que le soleil tourne autour de la Terre. Puis plus tard, quand il a mûri, on lui apprend qu'en fait c'est la Terre qui tourne autour du soleil. Ensuite on lui apprend que la Terre est ronde. Plus tard, s'il devient géographe, on lui apprendra que la Terre a en réalité la forme d'une patate. Dans le même temps on lui a appris les formules de l'accélération des corps selon Newton (v=gt). Si plus tard il devient physicien on lui expliquera que ces formules se complètent par celles d'Einstein qui ramène tout ça à un pourcentage de c (sinon, avec un "t" assez grand, cette formule fait dépasser la vitesse de la lumière). Et etc etc.

En Python c'est pareil. Un tutoriel t'apprendra des notions de base, ex les listes et comment leur ajouter des trucs via append() dans une boucle. Plus tard tu apprends les listes en comprehension et hop, exit le append(). Il t'apprendra aussi les modules, comment créer tes propres modules et les inclure dans ton programme de façon simple. Puis plus tard tu apprends qu'on peut placer des modules ailleurs dans l'arborescence et comment alors les récupérer via sys.path. Etc etc etc etc. Celui qui veut devenir "docteur ès Python" lui il apprendra sûrement d'autres trucs encore plus pointus, trucs dont tu n'auras jamais entendu parler ou dont tu n'auras jamais l'utilité (ex les métaclasses). Or tu remarqueras que les métaclasses n'apparaissent pas dans le tutoriel de Serge Tahé (ni celui de Swinnen). Et je fais du Python depuis 2007, je ne les ai apprises qu'il y a 3 mois...

[popo]

Tout ce que tu dis ne contredit en rien mon propos.
A un moment donné, les modules seront abordés et la problématique décrite dans les chapitres 9.4 et 9.5 du tutoriel mentionné sera rencontrée.
Afin d'expliquer à un étudiant pourquoi il rencontre l'erreur ModuleNotFoundError, il faut connaître la notion de sys_path

[Sve@r]

Afin d'expliquer à un étudiant pourquoi il rencontre l'erreur ModuleNotFoundError, il faut connaître la notion de sys_path

Afin d'expliquer à un étudiant pourquoi il rencontre l'erreur ModuleNotFoundError, il faut lui expliquer comment Python cherche ses modules et donc pourquoi il peut arriver qu'il ne les trouve pas (l'erreur du programmeur ça arrive aussi et peut-être plus souvent que mettre ses modules ailleurs pour ensuite devoir aller indiquer à Python où ils sont).
Ensuite tu peux lui corriger (ou donner un exemple) dans lequel cette situation ne se produit pas. Reprenons le chapitre 9.4 que tu as cité:

• dans le fichier "main.py" tu remplaces from module4 import f4 par un from dir2.module4 import f4 parce que du point de vue du main.py, le fichier "module4.py" se trouve dans le dossier "dir2"
• dans le fichier "dir2/module4.py" tu remplaces from module3 import f3 par from dir1.module3 import f3 parce que, toujours du même point de vue du main.py qui reste le programme de base à l'origine de l'instuction, le fichier "module3.py" se trouve dans le dossier "dir1"

Et plus d'erreur.

Ou enfin tu peux (ce n'est pas une obligation, tout dépend du but que tu veux atteindre dans cet apprentissage) lui expliquer à quoi sert sys.path dans la recherche des modules (accessoirement il s'agit de l'attribut "path" de l'objet "sys" et non "sys_path").

Accessoirement (avis personnel), concernant le chapitre 9.5 que je suis en train de regarder pour voir si modifier sys.path est ou n'est pas nécessaire, écrire un chemin de fichier en dur dans son exemple (ici config_filename="C:/Data/st-2020/dev/python/cours-2020/python3-flask-2020/import/05/config.json") c'est assez moyen question portabilité. Bon cela ne m'incite pas (pas encore) à dire qu'il ne sait pas de quoi il parle mais c'est une remarque à noter.

Dans le chapitre 9.6, il crée carrément une routine pour le faire.
Cette routine il la met ensuite dans un packages myutils qu'il installe dans l'environnement et tout les autres chapitres ont des config.py qui s'appuient sur la routine crée au chapitre 9.6

Oui je vois à peu près l'idée. Il essaye de créer un environnement "modulable". Les noms des dossiers étant alors inclus dans le fichier de config, si un nom de dossier de module change, il répercute le changement dans le fichier de config et tous les import se remettent à fonctionner.
Mais bon cela ne résout pas non plus toutes les situations. Dans tous ses exemples, les noms des modules sont distincts (fichier "dir1/module3.py", fichier "dir2/module4.py"). Imaginons maintenant une arborescence style fichier "dir1/moduleX.py", fichier "dir2/moduleX.py", cette façon de faire trouve alors rapidement ses limites.
Alors qu'en nommant l'import de façon directe (import dir1.moduleX ou import dir2.moduleX selon ton besoin) tu clarifies la situation.

[wiztricks]

Afin d'expliquer à un étudiant pourquoi il rencontre l'erreur ModuleNotFoundError, il faut connaître la notion de sys_path

Ce qu'on explique dépend du niveau de l'audience, des objectifs à atteindre i.e. ce qu'on veut que l'étudiant maîtrise à la sortie et les notions survolées qu'il devra approfondir.

Si c'est un débutant en programmation, il n'aura pas besoin de découper son programme en modules sauf peut être pour y déporter la définition de quelques fonctions.
Dans ce cas, le module n'a aucune raison d'être ailleurs que dans le répertoire du script principal et l'erreur lui signale juste une faute d'orthographe.
Imaginez un élève de 4ème qui patauge déjà avec la programmation... Pensez vous sérieusement que lui présenter sys.path va lui apporter quelque chose pour corriger une faute d'orthographe?

Si ce n'est pas un débutant en programmation, il est grand et peut lire le tutoriel qui vient avec Python, aller regarder le chapitre qui décrit les exceptions natives ce que signifie ModuleNotFoundError et avoir la curiosité d'aller lire les renvois sur sys.modules (qui n'est pas loin de sys.path).

On va peut être aborder çà dans le cours si çà a une quelconque utilité dans les exercices/projets demandés (ce qui reste à voir) histoire que tout le monde ait le même niveau d'information.

Comme on sait qu'on ne pourra pas tout aborder, le but pourra être de dégrossir un peu le problème histoire qu'ils puissent ensuite aller compléter leur formation en n'étant pas trop perdus avec la documentation officielle. Car les informations complètes et à jour sur Python sont là et pas ailleurs!

note: de toutes façons, il n'est pas facile de comprendre les modules Python sans avoir bien progressé dans la compréhension des classes... et comme Python est assez spécial, c'est pas tout de suite.

- W

[popo]

Sve@r voilà, la preuve par l'exemple qu'un prof à qui on demande du jour au lendemain d'enseigner le python alors qu'il n'en a jamais fait, ne pourra pas être totalement efficace. S'il n'est pas encadré dans son apprentissage (c'est triste à dire mais rarement le cas), il va lire des documents qui vont le faire partir dans une direction et enseigner cette même façon de faire à ces élèves.

Là vous venez de me montrer les limites d'une façon de faire d'un tutoriel sur lequel j'ai basé mon raisonnement. Je ne peux que constater que ce tutoriel m'a fait partir dans une direction que vous ne recommandez pas. Si j'ai fait l'erreur de penser qu'il s'agissait d'une pratique commune et recommandée, j'ose croire que d'autres la feront aussi.

Pour le chemin absolu en dur, ce problème est abordé et résolu par le calcul du chemin absolu via os.path.dirname(os.path.abspath(__file__))

[popo]

Imaginez un élève de 4ème qui patauge déjà avec la programmation... Pensez vous sérieusement que lui présenter sys.path va lui apporter quelque chose pour corriger une faute d'orthographe?

- W

En quatrième peut etre pas.
En quatrième il n'a pas trop le choix.
En terminale, s'il fait encore du python, c'est qu'il a choisi de s'engager dans une voie où on fait de la programmation
Et au lycée, où on attend d'un étudiant qu'il sache organiser son code un minimum, oui je lui toucherai un mot sur sys.path même si c'est uniquement pour lui parler des exceptions qui impose de le modifier. Pour qu'il sache quoi chercher dans la documentation lorsque l'occasion se présentera.

[Sve@r]

Sve@r voilà, la preuve par l'exemple qu'un prof à qui on demande du jour au lendemain d'enseigner le python alors qu'il n'en a jamais fait, ne pourra pas être totalement efficace. S'il n'est pas encadré dans son apprentissage (c'est triste à dire mais rarement le cas), il va lire des documents qui vont le faire partir dans une direction et enseigner cette même façon de faire à ces élèves.

Ce sera pareil en Delphi, en PHP, en C, en mathématiques, en histoire, en biologie, bref en tout ce qui est scientifique. Un prof de n'importe quoi ne peut pas enseigner ce "n'importe quoi" s'il ne le maitrise pas. Que l'Education Nationale considère l'apprentissage de Python tellement peanut qu'ils y balancent des profs dessus en les tirant à la courte paille est bien triste mais ce n'est pas la faute des profs. Ni celle de Python.

Là vous venez de me montrer les limites d'une façon de faire d'un tutoriel sur lequel j'ai basé mon raisonnement. Je ne peux que constater que ce tutoriel m'a fait partir dans une direction que vous ne recommandez pas. Si j'ai fait l'erreur de penser qu'il s'agissait d'une pratique commune et recommandée, j'ose croire que d'autres la feront aussi.

Moui je veux bien. Un tutoriel reste un travail bénévole et peut avoir des défauts. Je me souviens à mes débuts avoir galéré pour comprendre comment itérer sur plusieurs tuples sans savoir qu'on pouvait les additionner mais je me suis accroché. Les tutoriels sont issus de la bonne volonté des gens qui ont envie de partager leurs connaissances et on fait avec. Mais ça reste valable pour tout (je me souviens aussi mes débuts du C où je galérais parce que je ne comprenais pas pourquoi un char x[5][10] ne pouvait pas devenir un char ** alors qu'un char *x[] le peut et j'avais appris le C dans le K&R, donc un livre vendu en librairie !!!). Quel que soit le tutoriel, tu ne pourras jamais éviter de devoir faire tes propres expériences et échecs.

oui je lui toucherai un mot sur sys.path même si c'est uniquement pour lui parler des exceptions qui impose de le modifier. Pour qu'il sache quoi chercher dans la documentation lorsque l'occasion se présentera.

C'est le principe de l'enseignement => faire progresser les autres en leur faisant partager nos propres expériences. A condition évidemment que tu ne lui dises pas que taper dans sys.path est une obligation quand on crée des modules