from - python modules list
usando__init__.py (2)
El contenido de __init__.py
se importa cuando importa un módulo dentro del paquete.
Está pasando por alto un tercer escenario, que es colocar las partes comunes en un módulo separado y luego hacer que los otros módulos lo importen, dejando __init__.py
para las cosas que se usarán fuera del paquete. Esta es la práctica que suelo seguir.
Tengo dificultades para entender los escenarios de uso o los objetivos de diseño de los archivos __init__.py
de __init__.py
en mis proyectos.
Supongamos que tengo el directorio ''modelo'' (se refiere como un paquete) que contiene los siguientes archivos
-
__init__.py
-
meta.py
-
solrmodel.py
-
mongomodel.py
-
samodel.py
Encontré dos formas de usar __init__.py
:
Tengo una definición común que debe usarse en
solrmodel.py
,mongomodel.py
,samodel.py
. ¿Puedo usar__init__.py
como una definición básica / común para todas las * clases de model.py? Esto significa que tengo que importar elmodel/__init__.py
.O bien,
__init__.py
tendrá definiciones importadas de solrmodel.py, mongomodel.py, samodel.py en sí mismo y permite la fácil importación de clases o funciones como esta:# file: __init__.py from mongomodel import * from solrmodel import * from samodel import *
(Soy consciente de que la
import *
no es recomendable y solo la utilicé como una convención)
No pude decidir entre los dos escenarios anteriores. ¿Hay más escenarios de uso para __init__.py
y puedes explicar el uso?
La gran mayoría de los archivos __init__.py
que escribo están vacíos, porque muchos paquetes no tienen nada que inicializar.
Un ejemplo en el que puedo desear la inicialización es cuando al momento de cargar el paquete quiero leer en una serie de datos de una vez por todas (desde archivos, un DB o la web, por ejemplo), en cuyo caso es mucho más agradable pon esa lectura en una función privada en __init__.py
del paquete en lugar de tener un "módulo de inicialización" separado e importar de manera redundante ese módulo de cada módulo real en el paquete (inútilmente repetitivo y propenso a errores: obviamente ese es un caso en el que con la garantía de que el paquete __init__.py
se carga una vez antes de que cualquier módulo en el paquete sea obviamente mucho más Pythonic!).
Para otras expresiones de opinión concretas y autorizadas, observe los diferentes enfoques adoptados en los diversos paquetes que forman parte de la biblioteca estándar de Python.