Discussion :

[patic]

Bonjour,

Je connais 3 façons d'importer un module, par exemple :
- import os
- from os import *
- from os import geteuid (exemple au hasard)

La deuxième méthode n'est à priori pas recommandé, au profit de la première.
Avec la première méthode, il faut préciser l'espace de nom avec chaque appel d'une méthode ou autre, par exemple os.geteuid().
Alors qu'avec la troisième méthode, on peut directement appelé geteuid() (à condition qu'il n'y ait pas de collision avec le module en cours bien sûr).

Débutant en python, je ne connais pas tous les noms des méthodes et lorsque je lis des exemples, je suis souvent perdu, et je dois rechercher à quel espace de nom fait référence chaque méthode, car ils utilisent généralement la troisième méthode. En effet, il est courant que des exemples soient restreints et ne présentent pas l'intégralité du code. Ce qui parait limpide pour certains ne l'est pas forcément pour les autres.

Ainsi pour me retrouver dans mon code, j'ai envie d'utiliser la première méthode et de préciser l'espace de nom à chaque fois, quitte à créer un alias plus court. J'ai pris cette habitude en écrivant du sql (cela ne peut qu'optimiser le traitement par le moteur).
Cependant, j'ai peur qu'avec la première méthode cela oblige à charger tout le module et donc à surcharger la mémoire inutilement. Est ce que ma peur est avérée ? je ne connais pas les entrailles de python pour y répondre, mais peut être quelqu'un parmi vous ?

Merci pour votre aide.

[VinsS]

Salut,

L'import de modules est un mécanisme assez complexe avec Python, mais on peut généralement simplifier en disant que seul ce qui est nécessaire à l'exécution du code est chargé en mémoire et seulement au moment utile.

Je ne pense pas qu'il y ait plus intérêt à utiliser la première ou la troisième méthode, ça me semble plus une question d'habitude.

[marco056]

Il y en a une quatrième, c'est d'utiliser un alias, par exemple :

Code :

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

import numpy as np

puis ensuite, par exemple

Code :

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

np.sin()

Cela permet de savoir par exemple qu'on utilise la fonction sinus du module numpy et non celle du module math, dont le comportement peut être différent.

[tyrtamos]

Bonjour,

Il m'est déjà arrivé d'utiliser un alias dans un cas un peu particulier. La fonction pow de base (exponentiation x**y) permet un 3ème argument pour faire une exponentiation modulaire. Mais pas la fonction pow du module math! Alors, quand on installe math avec "from math import *", le pow de math masque le pow de base, et la partie modulaire devient impossible.

La solution: faire comme ça:

Code :

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

1
2
3
4
5
from builtins import pow as powmod
from math import *
 
print(powmod(2,3,2)) # => utilisation du pow de base
print(pow(2,3)) # => utilisation du pow de math

Autre remarque sur le sujet: dans certains cas de programme, la 3ème solution est meilleure sur le plan sécurité parce qu'elle permet d'éviter certaines injections.

Enfin, ne pas oublier des outils comme pylint pendant le développement: cet outil permet de détecter les importations inutiles ou manquantes. On peut donc commencer par une importation "attrappe tout" (from xxx import *) pendant le développement, et préciser à la fin la liste des objets à importer en utilisant pylint.

[patic]

Merci pour vos réponses.

Donc l'utilisation de la première méthode n'impacterait pas la mémoire plus que nécessaire ?

Effectivement, je connais la notation avec un alias, et c'est d'ailleurs la pratique que je préfère, car comme vous l'avez dit, cela permet plus facilement d’identifier l'espace de nom utilisé.

D'autres avis peut être ?

[patic]

Je viens seulement de lire la dernière réponse.

Je ne connaissais pas la notation avec un alias sur la forme "from x import y as z". Cela pourrait être une solution à mon problème.

Je pensais que dans le cas d'une collision entre deux fonctions de même nom, cela levait une exception. C'est d'autant plus dangereux, car on ne sait pas quelle fonction est réellement appelée. Je viens d'essayer en créant la fonction pi() dans mon code et en important pi du module math en entête, et c'est ma fonction qui a été retenue (à cause de l'ordre dans le code apparemment). Je n'aime pas ce genre de comportement ambigu.

Je n'ai pas compris le problème de sécurité (injection).

Sinon, je débute et je ne connais pas encore les différentes possibilités d'amélioration du code, mais j'y travaille, donc merci pour l'astuce concernant pylint.

[wiztricks]

Salut,

Ainsi pour me retrouver dans mon code, j'ai envie d'utiliser la première méthode et de préciser l'espace de nom à chaque fois, quitte à créer un alias plus court. J'ai pris cette habitude en écrivant du sql (cela ne peut qu'optimiser le traitement par le moteur).
Cependant, j'ai peur qu'avec la première méthode cela oblige à charger tout le module et donc à surcharger la mémoire inutilement. Est ce que ma peur est avérée ? je ne connais pas les entrailles de python pour y répondre, mais peut être quelqu'un parmi vous ?

Quelque soit la méthode, le module sera chargé (si d'autres "import" ne l'ont pas déjà fait).
Pour le reste ce qui change, c'est d'abord les variables ajoutés à l'espace globals():

• import os: seul "os" sera ajouté,
• from os import *: toutes les variables publiques du module sont ajoutées.
• from os import geteuid: seul "getuid" sera ajouté...

Au plus il y aura d'ajouts, au plus la durée de l'import sera longue. Ce qui fera préférer les formes 1 et 3 à la deuxième.... Et réserver la deuxième plutôt à des tests avec l'interpréteur interactif (ce qui évite d'avoir à tout taper).

Donc il vous reste 1 ou 3... et c'est sur que liste "os.geteuid" sera probablement plus parlant que "geteuid" tout seul. Et côté performances, trouver à quoi est associé "os" puis récupérer l'objet associé à "geteuid", çà fait une indirection qui peut être sensible lorsqu'on fait des itérations.
(mais rien n'interdit d'optimiser avec la création d'une variable "locale" geteuid = os.geteuid juste avant ces itérations).

D'autre part, au plus vous allez progresser au plus vous utiliserez des objets, utiliser des variables associées à un espace de noms autre que globals(): instance.machin, module.truc,... sont des notations qui alertent sur le fait que "machin" et "truc" ne sont ni variables locales ni variables globales mais viennent d'ailleurs...

Pour ce qui est des alias - import numpy as np -, ils permettent d'abord de vous éviter de taper trop de caractères mais dans le cas "import Tkinter as tk" de Python2 vs. "import tkinter as tk" de Python3, çà permet aussi de réduire les changements à faire dans le code lorsque le nom du module change.

Je n'ai fait que lister quelques bonnes raisons de préférer une forme par rapport à une autre. Mais dans la vraie vie, il y a toujours des exceptions qui rendent illusoire de vouloir appliquer la même règle partout. Il faut donc s'adapter au contexte (et savoir pourquoi on fait ici et maintenant un peu différemment de ce qu'on a pu faire hier).

En tous cas, bonne année à tous.

- W

[patic]

Merci pour ces explications fort intéressantes,

et bonne année à vous tous également