Dois-je utiliser `import os.path` ou` import os`?

Selon la documentation officielle , os.pathest un module. Quelle est donc la manière préférée de l'importer?

# Should I always import it explicitly?
import os.path

Ou...

# Is importing os enough?
import os

Veuillez NE PAS répondre "l'importation de ostravaux pour moi". Je sais, cela fonctionne aussi pour moi en ce moment (à partir de Python 2.6). Ce que je veux savoir, c'est toute recommandation officielle à ce sujet. Donc, si vous répondez à cette question, veuillez poster vos références .

os.pathfonctionne d'une manière amusante. Cela ressemble à osun package avec un sous-module path, mais en réalité, osc'est un module normal qui fait de la magie sys.modulespour injecter os.path. Voici ce qui se passe:

• Lorsque Python démarre, il charge un tas de modules dans sys.modules. Ils ne sont liés à aucun nom dans votre script, mais vous pouvez accéder aux modules déjà créés lorsque vous les importez d'une manière ou d'une autre.

  • sys.modulesest un dict dans lequel les modules sont mis en cache. Lorsque vous importez un module, s'il a déjà été importé quelque part, il obtient l'instance stockée dans sys.modules.

• osfait partie des modules chargés au démarrage de Python. Il affecte son pathattribut à un module de chemin spécifique au système d'exploitation.

• Il injecte de sys.modules['os.path'] = pathsorte que vous puissiez faire " import os.path" comme s'il s'agissait d'un sous-module.

J'ai tendance à penser os.pathà un module que je veux utiliser plutôt qu'à une chose dans le osmodule , donc même si ce n'est pas vraiment un sous-module d'un package appelé os, je l'importe un peu comme si c'était un et je le fais toujoursimport os.path . Ceci est cohérent avec la façon dont os.pathest documenté.

Incidemment, ce type de structure conduit à beaucoup de confusion précoce des programmeurs Python sur les modules et les packages et l'organisation du code, je pense. C'est vraiment pour deux raisons

1. Si vous pensez osà un package et que vous savez que vous pouvez faire import oset avoir accès au sous-module os.path, vous pourriez être surpris plus tard de ne pas pouvoir le faire import twistedet y accéder automatiquement twisted.spreadsans l'importer.

2. Il est déroutant que ce os.namesoit une chose normale, une chaîne et os.pathun module. Je structure toujours mes packages avec des __init__.pyfichiers vides de sorte qu'au même niveau j'ai toujours un type de chose: un module / package ou autre. Plusieurs grands projets Python adoptent cette approche, qui tend à rendre le code plus structuré.

Selon PEP-20 de Tim Peters, «l'explicite est meilleur que l'implicite» et «la lisibilité compte». Si tout ce dont vous avez besoin du osmodule est sous os.path, import os.pathserait plus explicite et laisser les autres savoir ce qui vous tient vraiment à cœur.

De même, PEP-20 dit également "Simple est mieux que complexe", donc si vous avez également besoin de choses qui se trouvent sous le osparapluie plus général , il import osserait préférable.

Réponse définitive: import oset utilisation os.path. pas import os.pathdirectement.

Depuis la documentation du module lui-même:

>>> import os
>>> help(os.path)
...
Instead of importing this module directly, import os and refer to
this module as os.path.  The "os.path" name is an alias for this
module on Posix systems; on other systems (e.g. Mac, Windows),
os.path provides the same operations in a manner specific to that
platform, and is an alias to another module (e.g. macpath, ntpath).
...

Il est intéressant de noter que l'importation de os.path importera tous les fichiers os. essayez ce qui suit dans l'invite interactive:

import os.path
dir(os)

Le résultat sera le même que si vous venez d'importer os. C'est parce que os.path fera référence à un module différent en fonction du système d'exploitation que vous avez, donc python importera os pour déterminer quel module charger pour le chemin.

référence

Avec certains modules, dire import foone sera pas exposé foo.bar, donc je suppose que cela dépend vraiment de la conception du module spécifique.

En général, importer simplement les modules explicites dont vous avez besoin devrait être légèrement plus rapide. Sur ma machine:

import os.path: 7.54285810068e-06 secondes

import os: 9.21904878972e-06 secondes

Ces temps sont suffisamment proches pour être assez négligeables. Votre programme peut avoir besoin d'utiliser d'autres modules à partir de osmaintenant ou plus tard, il est donc généralement logique de simplement sacrifier les deux microsecondes et de les utiliser import ospour éviter cette erreur plus tard. Je suis généralement d'accord avec l'importation d'os dans son ensemble, mais je peux voir pourquoi certains préféreraient import os.pathêtre techniquement plus efficaces et transmettre aux lecteurs du code que c'est la seule partie du osmodule qui devra être utilisée. Cela se résume essentiellement à une question de style dans mon esprit.

Le bon sens fonctionne ici: osest un module, et os.pathest aussi un module. Alors importez simplement le module que vous souhaitez utiliser:

• Si vous souhaitez utiliser les fonctionnalités du osmodule, importez os.

• Si vous souhaitez utiliser les fonctionnalités du os.pathmodule, importez os.path.

• Si vous souhaitez utiliser des fonctionnalités dans les deux modules, importez les deux modules:

  import os
  import os.path

Pour référence:

• Lib / idlelib / rpc.py utilise oset importe os.

• Lib / idlelib / idle.py utilise os.pathet importe os.path.

• Lib / ensurepip / init .py utilise les deux et importe les deux.

Impossible de trouver une référence définitive, mais je vois que l'exemple de code pour os.walk utilise os.path mais importe seulement os