- Formations
- conversion_path Parcours & Formations
- science Projets
- data_object Exercices de code
- psychology Exercices IA
- quiz Quiz
- Articles
- rss_feed Blog
- sort_by_alpha Glossaire
- menu_book Guides
- help_center FAQ
- media_link Ressources
- Communauté
- groups La communauté
- forum Questions
- live_tv Mentorats
- science Projets mensuels
- Formations
- conversion_path Parcours & Formations
- science Projets
- data_object Exercices de code
- psychology Exercices IA
- quiz Quiz
- Articles
- rss_feed Blog
- sort_by_alpha Glossaire
- menu_book Guides
- help_center FAQ
- media_link Ressources
- Communauté
- groups La communauté
- forum Questions
- live_tv Mentorats
- science Projets mensuels
Inscris-toi
(c'est gratuit !)
Un compte est nécessaire pour participer aux discussions.
Créer un compte person00:00:00 :On vous a déjà sûrement indiqué que c'était une très mauvaise idée d'importer toutes lesfonctions à l'intérieur d'un module de cette façon, donc avec la syntaxe from os importétoile. Dans cette vidéo, on va voir pourquoi c'est une mauvaise idée et dans quel cas ça
00:00:13 :peut causer des problèmes. Dans cet exemple, j'ai déclaré ici une variable path qui pointe vers unfichier effectif sur mon disque dur, et ensuite j'importe toutes les fonctions qui sont contenuesà l'intérieur du module os, donc avec cette syntaxe, et ensuite je vais printer ici ma variablepath. Donc j'exécute le script et là vous voyez que je n'ai pas le chemin vers mon fichier qui
00:00:32 :s'affiche, mais plutôt le module ntpath qui est contenu dans les librairies de Python 27. Alorspourquoi ça fait ça ? Et bien tout simplement puisque quand on utilise cette syntaxe ici,
00:00:42 :on ne va pas avoir besoin de préfixer les fonctions qui vont être contenues dans le module par le nomdu module. Donc si je veux accéder à la fonction path qui est à l'intérieur du module os, et bien
00:00:53 :je vais tout simplement pouvoir écrire path pour y avoir accès, alors que si je faisais un importnormal, donc comme ceci, import os, il faudrait que j'y accède en faisant os.path. Donc c'est sûr
00:01:04 :que ça peut être un peu rébarbatif à la longue d'avoir à écrire tout le temps os.path, mais c'estvraiment un gros avantage puisque en faisant ceci, vous évitez de rentrer en conflit avec votre autrevariable ici que vous avez déclarée. Alors c'est pour ça que c'est une erreur qui peut être assez
00:01:17 :sournoise, puisque ça peut arriver assez tard dans le développement de votre script, c'est-à-dire quevous pouvez fonctionner très bien avec ce type d'import pendant les 80% du développement devotre script, et à un moment vous allez déclarer une variable path, et là ça va rentrer en conflitavec d'autres noms que vous aurez importés. Si vous faites import os comme ceci, et bien vous vous
00:01:35 :assurez de ne pas avoir de limiter en fait vos conflits, puisque vous allez avoir besoin depréfixer avec le nom du module, et donc ils vont chacun être dans un namespace différent. Si je
00:01:46 :fais un print ici de deer sans rien lui donner à l'intérieur des parenthèses, ça va nous affichertout ce qui est contenu dans le namespace global à mon script. Donc là je vais exécuter le script,
00:01:55 :et là vous voyez qu'en faisant from os import étoile, on a importé toutes ces fonctionsici directement dans l'espace global de notre script. Donc si on crée une fonction ici qui
00:02:05 :s'appelle par exemple open, enfin pas une fonction mais une variable qui s'appelle open, ou comme onvient de le faire path ici, et bien on va rentrer en conflit avec toutes ces fonctions qu'on aimportées. Si par contre ici je fais import os à la place, donc je vais commenter cette ligne ici,
00:02:19 :j'exécute, là vous allez voir qu'on a uniquement le module os qui est importé, et path ici,donc path qui correspond cette fois-ci à ma variable que j'ai définie plus haut. Donc là
00:02:30 :vous voyez qu'on a beaucoup moins de noms qui sont inclus directement dans le namespace global,et donc ça va limiter grandement le risque de clash entre des variables que je vais définiret des variables qu'on aurait importées donc directement dans le namespace global avec cettesyntaxe ici. Donc voilà pourquoi c'est vraiment une mauvaise idée d'importer toutes les fonctions
00:02:48 :comme ça, et voilà pourquoi il est préférable, même si c'est un petit peu plus long à chaquefois, de toujours préfixer avec le nom du module, comme ça au moins on sait d'où ça vient, on saitque la fonction path elle va venir du module os, et que ce n'est pas tout simplement une variable
00:03:01 :qu'on aurait définie précédemment et qui pourrait rentrer en conflit avec. Donc j'espère que ça adémystifié un peu le pourquoi c'est une mauvaise idée de faire cet import. Moi on m'a toujours dit
00:03:12 :que c'était une mauvaise idée mais on m'a rarement expliqué pourquoi, donc j'espère qu'avec ça vouspouvez voir vraiment le danger en fait d'importer tous les noms comme ça dans l'espace global,puisque vous êtes presque assuré si vous faites ça pour tous vos modules, là on a un seul module
00:03:25 :mais imaginez que vous faites ça pour tous vos modules pour vous éviter d'avoir à taper le nomdu module et le nom de la fonction, eh bien vous allez avoir énormément de noms de fonctions quivont être importés directement dans l'espace global et vous allez très très très probablement
00:03:38 :vous retrouver avec des conflits, avec des variables que vous allez avoir définies. Doncvoilà pourquoi c'est une très mauvaise idée de faire ça, donc je vous conseille vraimentd'utiliser uniquement cette syntaxe et de ne plus utiliser cette syntaxe à part dans des cas trèsprécis où vous savez exactement ce que vous faites et où ça peut peut-être vous simplifier la vie.
Ce n'est pas fini...
✋
Tu as complété % du parcours 🔥
Termine l'intégralité de la formation pour pouvoir débloquer ton attestation de réussite.