Puede que se de el caso de que encuentres algún problema en tu código o trabajo, recuerda probar siempre en un entorno de testing antes subir el código al proyecto final.
Solución:
os.path
funciona de una manera divertida. Parece que os
debe ser un paquete con un submódulo path
Pero en la realidad os
es un módulo normal que hace magia con sys.modules
inyectar os.path
. Esto es lo que sucede:
-
Cuando se inicia Python, carga un montón de módulos en
sys.modules
. No están vinculados a ningún nombre en su secuencia de comandos, pero puede acceder a los módulos ya creados cuando los importa de alguna manera.sys.modules
es un dict en el que los módulos se almacenan en caché. Cuando importa un módulo, si ya se ha importado en algún lugar, obtiene la instancia almacenada ensys.modules
.
-
os
es uno de los módulos que se cargan cuando se inicia Python. le asigna supath
attribute a un módulo de ruta específico del sistema operativo. -
se inyecta
sys.modules['os.path'] = path
para que seas capaz de hacer “import os.path
como si fuera un submódulo.
Tiendo a pensar en os.path
como un módulo que quiero usar en vez de una cosa en el os
móduloasí que aunque no es De Verdad un submódulo de un paquete llamado os
lo importo como si fuera uno y Siempre hago import os.path
. Esto es consistente con la forma en que os.path
está documentado.
Por cierto, creo que este tipo de estructura conduce a una gran confusión inicial de los programadores de Python sobre los módulos y paquetes y la organización del código. Esto es realmente por dos razones
-
si piensas en
os
como un paquete y saber que puedes hacerimport os
y tener acceso al submóduloos.path
puede que te sorprendas más tarde cuando no puedas hacerimport twisted
y acceder automáticamentetwisted.spread
sin importarlo. -
es confuso que
os.name
es algo normal, un stringyos.path
es un modulo Siempre estructuro mis paquetes con vacío__init__.py
archivos para que en el mismo nivel siempre tenga un tipo de cosa: un módulo/paquete u otras cosas. Varios grandes proyectos de Python adoptan este enfoque, que tiende a crear un código más estructurado.
Según PEP-20 de Tim Peters, “Explícito es mejor que implícito” y “La legibilidad cuenta”. Si todo lo que necesita del os
el modulo esta debajo os.path
, import os.path
Sería más explícito y permitiría que los demás supieran lo que realmente te importa.
Del mismo modo, PEP-20 también dice “Simple es mejor que complejo”, por lo que si también necesita cosas que residen en el más general os
paraguas, import os
sería preferible
Respuesta definitiva: import os
y use os.path
. no import os.path
directamente.
De la documentación del propio módulo:
>>> 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).
...
Acuérdate de que te permitimos reseñar tu experiencia si te ayudó.