importlib
— A implementação de import
¶
Adicionado na versão 3.1.
Código-fonte: Lib/importlib/__init__.py
Introdução¶
O pacote importlib
tem três propósitos.
Uma é fornecer a implementação da instrução import
(e, portanto, por extensão, a função __import__()
) no código-fonte Python. Isso fornece uma implementação de import
que é portável para qualquer interpretador Python. Isso também fornece uma implementação que é mais fácil de compreender do que aquela implementada em uma linguagem de programação diferente do Python.
Dois, os componentes para implementar import
são expostos neste pacote, tornando mais fácil para os usuários criarem seus próprios objetos personalizados (conhecidos genericamente como importador) para participar do processo de importação.
Terceiro, o pacote contém módulos que expõem funcionalidades adicionais para gerenciar aspectos de pacotes Python:
importlib.metadata
apresenta acesso a metadados de distribuições de terceiros.importlib.resources
fornece rotinas para acessar “recursos” não codificados de pacotes Python.
Ver também
- A instrução import
A referência da linguagem para a instrução
import
.- Especificação dos pacotes
Especificação original dos pacotes. Algumas semânticas mudaram desde a redação deste documento (por exemplo, redirecionamento baseado em
None
emsys.modules
).- A função
__import__()
A instrução
import
é um açúcar sintático para esta função.- A inicialização do caminho de pesquisa de módulos sys.path
A inicialização de
sys.path
.- PEP 235
Importação em plataformas que diferenciam maiúsculo de minúsculo
- PEP 263
Definindo codificações do código-fonte do Python
- PEP 302
Novos ganchos de importação
- PEP 328
Importações: Multilinha e Absoluto/Relativo
- PEP 366
Importações relativas explícitas do módulo principal
- PEP 420
Pacotes de espaço de nomes implícitos
- PEP 451
Um tipo de ModuleSpec para o sistema de importação
- PEP 488
Eliminação de arquivos PYO
- PEP 489
Inicialização de módulo extensão multifase
- PEP 552
pycs determinísticos
- PEP 3120
Usando UFT-8 como fonte padrão de codificação
- PEP 3147
Diretórios de repositório de PYC
Funções¶
- importlib.__import__(name, globals=None, locals=None, fromlist=(), level=0)¶
Uma implementação da função embutida
__import__()
.Nota
A importação programática de módulos deve usar
import_module()
em vez desta função.
- importlib.import_module(name, package=None)¶
Importa um módulo. O argumento name especifica qual módulo importar em termos absolutos ou relativos (por exemplo,
pkg.mod
ou..mod
). Se o nome for especificado em termos relativos, então o argumento package deve ser definido como o nome do pacote que atuará como âncora para resolver o nome do pacote (por exemplo,import_module('..mod', 'pkg.subpkg')
importarápkg.mod
).A função
import_module()
atua como um wrapper simplificador em torno deimportlib.__import__()
. Isso significa que toda a semântica da função é derivada deimportlib.__import__()
. A diferença mais importante entre essas duas funções é queimport_module()
retorna o pacote ou módulo especificado (por exemplo,pkg.mod
), enquanto__import__()
retorna o pacote ou módulo de nível superior (por exemplo,pkg
).Se você estiver importando dinamicamente um módulo que foi criado desde que o interpretador iniciou a execução (por exemplo, criou um arquivo fonte Python), você pode precisar chamar
invalidate_caches()
para que o novo módulo seja notado pelo sistema de importação.Alterado na versão 3.3: Os pacotes pai são importados automaticamente.
- importlib.invalidate_caches()¶
Invalida os caches internos dos localizadores armazenados em
sys.meta_path
. Se um localizador implementarinvalidate_caches()
então ele será chamado para realizar a invalidação. Esta função deve ser chamada se algum módulo for criado/instalado enquanto seu programa estiver em execução para garantir que todos os localizadores notarão a existência do novo módulo.Adicionado na versão 3.3.
Alterado na versão 3.10: Pacotes de espaço de nomes criados/instalados em um local
sys.path
diferente após o mesmo espaço de nomes já ter sido importado são notados.
- importlib.reload(module)¶
Recarrega um module importado anteriormente. O argumento deve ser um objeto módulo, portanto deve ter sido importado com êxito antes. Isso é útil se você editou o arquivo fonte do módulo usando um editor externo e deseja experimentar a nova versão sem sair do interpretador Python. O valor de retorno é o objeto módulo (que pode ser diferente se a reimportação fizer com que um objeto diferente seja colocado em
sys.modules
).Quando
reload()
é executado:O código do módulo Python é recompilado e o código em nível de módulo é reexecutado, definindo um novo conjunto de objetos que são vinculados a nomes no dicionário do módulo reutilizando o carregador que originalmente carregou o módulo. A função
init
dos módulos de extensão não é chamada uma segunda vez.Tal como acontece com todos os outros objetos em Python, os objetos antigos só são recuperados depois que suas contagens de referências caem para zero.
Os nomes no espaço de nomes do módulo são atualizados para apontar para quaisquer objetos novos ou alterados.
Outras referências aos objetos antigos (como nomes externos ao módulo) não são religadas para se referir aos novos objetos e devem ser atualizadas em cada espaço de nomes onde ocorrem, se isso for desejado.
Existem várias outras ressalvas:
Quando um módulo é recarregado, seu dicionário (contendo as variáveis globais do módulo) é retido. As redefinições de nomes vão substituir as definições antigas, portanto isso geralmente não é um problema. Se a nova versão de um módulo não definir um nome definido pela versão antiga, a definição antiga permanecerá. Este recurso pode ser usado para vantagem do módulo se ele mantiver uma tabela global ou cache de objetos – com uma instrução
try
ele pode testar a presença da tabela e pular sua inicialização se desejar:try: cache except NameError: cache = {}
Geralmente não é muito útil recarregar módulos embutidos ou carregados dinamicamente. Recarregar
sys
,__main__
,builtins
e outros módulos principais não é recomendado. Em muitos casos, os módulos de extensão não são projetados para serem inicializados mais de uma vez e podem falhar de maneiras arbitrárias quando recarregados.Se um módulo importa objetos de outro módulo usando
from
…import
…, chamarreload()
para o outro módulo não redefine os objetos importados dele – uma maneira de contornar isso é executar novamente a instruçãofrom
, outra é usarimport
e nomes qualificados (module.name).Se um módulo instancia instâncias de uma classe, recarregar o módulo que define a classe não afeta as definições de método das instâncias – elas continuam a usar a definição de classe antiga. O mesmo se aplica às classes derivadas.
Adicionado na versão 3.4.
Alterado na versão 3.7:
ModuleNotFoundError
é levantada quando o módulo que está sendo recarregado não possui umModuleSpec
.
importlib.abc
– classes base abstratas relacionadas a importação¶
Código-fonte: Lib/importlib/abc.py
O módulo importlib.abc
contém todas as principais classes base abstratas usadas por import
. Algumas subclasses das classes base abstratas principais também são fornecidas para ajudar na implementação dss ABCs principais.
Hierarquia de ABC:
object
+-- MetaPathFinder
+-- PathEntryFinder
+-- Loader
+-- ResourceLoader --------+
+-- InspectLoader |
+-- ExecutionLoader --+
+-- FileLoader
+-- SourceLoader
- class importlib.abc.MetaPathFinder¶
Uma classe base abstrata que representa um localizador de metacaminho.
Adicionado na versão 3.3.
Alterado na versão 3.10: Não é mais uma subclasse de
Finder
.- find_spec(fullname, path, target=None)¶
An abstract method for finding a spec for the specified module. If this is a top-level import, path will be
None
. Otherwise, this is a search for a subpackage or module and path will be the value of__path__
from the parent package. If a spec cannot be found,None
is returned. When passed in,target
is a module object that the finder may use to make a more educated guess about what spec to return.importlib.util.spec_from_loader()
may be useful for implementing concreteMetaPathFinders
.Adicionado na versão 3.4.
- invalidate_caches()¶
Um método opcional que, quando chamado, deve invalidar qualquer cache interno usado pelo localizador. Usado por
importlib.invalidate_caches()
ao invalidar os caches de todos os localizadores emsys.meta_path
.Alterado na versão 3.4: Retorna
None
quando chamado em vez deNotImplemented
.
- class importlib.abc.PathEntryFinder¶
Uma classe base abstrata que representa um localizador de entrada de caminho. Embora tenha algumas semelhanças com
MetaPathFinder
,PathEntryFinder
deve ser usado apenas dentro do subsistema de importação baseado em caminho fornecido porimportlib.machinery.PathFinder
.Adicionado na versão 3.3.
Alterado na versão 3.10: Não é mais uma subclasse de
Finder
.- find_spec(fullname, target=None)¶
Um método abstrato para encontrar um spec para o módulo especificado. O localizador irá procurar pelo módulo apenas dentro do entrada de caminho ao qual ele está atribuído. Se uma especificação não puder ser encontrada,
None
será retornado. Quando passado,target
é um objeto de módulo que o localizador pode usar para fazer uma estimativa mais informada sobre qual especificação retornar.importlib.util.spec_from_loader()
pode ser útil para implementarPathEntryFinders
concretos.Adicionado na versão 3.4.
- invalidate_caches()¶
Um método opcional que, quando chamado, deve invalidar qualquer cache interno usado pelo localizador. Usado por
importlib.machinery.PathFinder.invalidate_caches()
ao invalidar os caches de todos os localizadores em cache.
- class importlib.abc.Loader¶
Uma classe base abstrata para um carregador. Veja PEP 302 para a definição exata de um carregador.
Carregadores que desejam oferecer suporte a leitura de recursos devem implementar um método
get_resource_reader()
conforme especificado porimportlib.resources.abc.ResourceReader
.Alterado na versão 3.7: Introduzido o método opcional
get_resource_reader()
.- create_module(spec)¶
Um método que retorna o objeto do módulo a ser usado ao importar um módulo. Este método pode retornar
None
, indicando que a semântica padrão de criação do módulo deve ocorrer.Adicionado na versão 3.4.
Alterado na versão 3.6: Este método não é mais opcional quando
exec_module()
é definido.
- exec_module(module)¶
Um método abstrato que executa o módulo em seu próprio espaço de nomes quando um módulo é importado ou recarregado. O módulo já deve estar inicializado quando
exec_module()
for chamado. Quando este método existir,create_module()
deve ser definido.Adicionado na versão 3.4.
Alterado na versão 3.6:
create_module()
deve ser definido.
- load_module(fullname)¶
Um método legado para carregar um módulo. Se o módulo não puder ser carregado,
ImportError
será levantada, caso contrário, o módulo carregado será retornado.Se o módulo solicitado já existir em
sys.modules
, esse módulo deverá ser usado e recarregado. Caso contrário, o carregador deve criar um novo módulo e inseri-lo emsys.modules
antes de qualquer carregamento começar, para evitar a recursão da importação. Se o carregador inseriu um módulo e o carregamento falhar, ele deverá ser removido pelo carregador desys.modules
; módulos já emsys.modules
antes do carregador iniciar a execução devem ser deixados sozinhos.O carregador deve definir vários atributos no módulo (observe que alguns desses atributos podem mudar quando um módulo é recarregado):
module.__cached__
(deprecated)module.__package__
(deprecated)module.__loader__
(deprecated)
Quando
exec_module()
está disponível, então a funcionalidade compatível com versões anteriores é fornecida.Alterado na versão 3.4: Levanta
ImportError
quando chamado em vez deNotImplementedError
. Funcionalidade fornecida quandoexec_module()
está disponível.Obsoleto desde a versão 3.4: A API recomendada para carregar um módulo é
exec_module()
(ecreate_module()
). Os carregadores devem implementá-lo em vez deload_module()
. O mecanismo de importação cuida de todas as outras responsabilidades deload_module()
quandoexec_module()
é implementado.
- class importlib.abc.ResourceLoader¶
Uma classe base abstrata para um carregador que implementa o protocolo opcional PEP 302 para carregar recursos arbitrários do back-end de armazenamento.
Obsoleto desde a versão 3.7: Este ABC foi descontinuado em favor do suporte ao carregamento de recursos por meio de
importlib.resources.abc.ResourceReader
.- abstractmethod get_data(path)¶
An abstract method to return the bytes for the data located at path. Loaders that have a file-like storage back-end that allows storing arbitrary data can implement this abstract method to give direct access to the data stored.
OSError
is to be raised if the path cannot be found. The path is expected to be constructed using a module’s__file__
attribute or an item from a package’s__path__
.Alterado na versão 3.4: Levanta
OSError
em vez deNotImplementedError
.
- class importlib.abc.InspectLoader¶
Uma classe base abstrata para um carregador que implementa o protocolo opcional da PEP 302 para carregadores que inspecionam módulos.
- get_code(fullname)¶
Retorna o objeto de código para um módulo, ou
None
se o módulo não tiver um objeto código (como seria o caso, por exemplo, para um módulo embutido). Levanta umImportError
se o carregador não conseguir encontrar o módulo solicitado.Nota
Embora o método tenha uma implementação padrão, sugere-se que ele seja substituído, se possível, para desempenho.
Alterado na versão 3.4: Não é mais abstrato e uma implementação concreta é fornecida.
- abstractmethod get_source(fullname)¶
Um método abstrato para retornar a fonte de um módulo. Ele é retornado como uma string de texto usando novas linhas universais, traduzindo todos os separadores de linha reconhecidos em caracteres
'\n'
. RetornaNone
se nenhuma fonte estiver disponível (por exemplo, um módulo embutido). LevantaImportError
se o carregador não puder encontrar o módulo especificado.Alterado na versão 3.4: Levanta
ImportError
em vez deNotImplementedError
.
- is_package(fullname)¶
Um método opcional para retornar um valor verdadeiro se o módulo for um pacote, um valor falso caso contrário.
ImportError
é levantada se o carregador não puder encontrar o módulo.Alterado na versão 3.4: Levanta
ImportError
em vez deNotImplementedError
.
- static source_to_code(data, path='<string>')¶
Cria um objeto código a partir de código-fonte Python
O argumento data pode ser qualquer coisa a qual a função
compile()
tenha suporte (por exemplo, string ou bytes). O argumento path deve ser o “caminho” de onde o código-fonte se originou, o que pode ser um conceito abstrato (por exemplo, local em um arquivo zip).Com o objeto de código subsequente, é possível executá-lo em um módulo executando
exec(code, module.__dict__)
.Adicionado na versão 3.4.
Alterado na versão 3.5: O método foi tornado estático.
- exec_module(module)¶
Implementação de
Loader.exec_module()
.Adicionado na versão 3.4.
- load_module(fullname)¶
Implementação de
Loader.load_module()
.Obsoleto desde a versão 3.4: use
exec_module()
.
- class importlib.abc.ExecutionLoader¶
Uma classe base abstrata que herda de
InspectLoader
que, quando implementada, ajuda um módulo a ser executado como um script. A ABC representa um protocolo opcional da PEP 302.- abstractmethod get_filename(fullname)¶
An abstract method that is to return the value of
__file__
for the specified module. If no path is available,ImportError
is raised.Se o código-fonte estiver disponível, o método deverá retornar o caminho para o arquivo fonte, independentemente de um bytecode ter sido usado para carregar o módulo.
Alterado na versão 3.4: Levanta
ImportError
em vez deNotImplementedError
.
- class importlib.abc.FileLoader(fullname, path)¶
Uma classe base abstrata que herda de
ResourceLoader
eExecutionLoader
, fornecendo implementações concretas deResourceLoader.get_data()
eExecutionLoader.get_filename()
.O argumento fullname é um nome totalmente resolvido do módulo que o carregador deve manipular. O argumento path é o caminho para o arquivo do módulo.
Adicionado na versão 3.3.
- name¶
O nome do módulo que o carregador pode manipular.
- path¶
Caminho para o arquivo do módulo
- load_module(fullname)¶
Chama
load_module()
do super.Obsoleto desde a versão 3.4: Use
Loader.exec_module()
- abstractmethod get_data(path)¶
Lê caminho como um arquivo binário e retorna os bytes dele.
- class importlib.abc.SourceLoader¶
Uma classe base abstrata para implementar o carregamento de arquivo fonte (e opcionalmente bytecode). A classe herda de
ResourceLoader
eExecutionLoader
, exigindo a implementação de:ExecutionLoader.get_filename()
Deve retornar apenas o caminho para o arquivo fonte; o carregamento sem fonte não é suportado.
Os métodos abstratos definidos por esta classe são para adicionar suporte opcional ao arquivo bytecode. Não implementar esses métodos opcionais (ou fazer com que eles levantem
NotImplementedError
) faz com que o carregador funcione apenas com código-fonte. Implementar os métodos permite que o carregador funcione com arquivos de código-fonte e bytecode; ele não permite carregamento sem fonte onde apenas o bytecode é fornecido. Arquivos de bytecode são uma otimização para acelerar o carregamento removendo a etapa de análise do compilador do Python e, portanto, nenhuma API específica de bytecode é exposta.- path_stats(path)¶
Método abstrato opcional que retorna um
dict
contendo metadados sobre o caminho especificado. As chaves de dicionário suportadas são:'mtime'
(obrigatório): um número inteiro ou de ponto flutuante que representa o tempo de modificação do código-fonte;'size'
(opcional): o tamanho em bytes do código-fonte.
Quaisquer outras chaves no dicionário são ignoradas, para permitir extensões futuras. Se o caminho não puder ser manipulado,
OSError
é levantada.Adicionado na versão 3.3.
Alterado na versão 3.4: Levanta
OSError
em vez deNotImplementedError
.
- path_mtime(path)¶
Método abstrato opcional que retorna o horário de modificação do caminho especificado.
Obsoleto desde a versão 3.3: Este método foi descontinuado em favor de
path_stats()
. Você não precisa implementá-lo, mas ele ainda está disponível para fins de compatibilidade. LevantaOSError
se o caminho não puder ser manipulado.Alterado na versão 3.4: Levanta
OSError
em vez deNotImplementedError
.
- set_data(path, data)¶
Método abstrato opcional que grava os bytes especificados em um caminho de arquivo. Quaisquer diretórios intermediários que não existam devem ser criados automaticamente.
Quando a gravação no caminho falhar porque o caminho é somente leitura (
errno.EACCES
/PermissionError
), não propaga a exceção.Alterado na versão 3.4: Não mais levanta
NotImplementedError
quando chamado.
- get_code(fullname)¶
Implementação concreta de
InspectLoader.get_code()
.
- exec_module(module)¶
Implementação concreta de
Loader.exec_module()
.Adicionado na versão 3.4.
- load_module(fullname)¶
Implementação concreta de
Loader.load_module()
.Obsoleto desde a versão 3.4: Use
exec_module()
.
- get_source(fullname)¶
Implementação concreta de
InspectLoader.get_source()
.
- is_package(fullname)¶
Implementação concreta de
InspectLoader.is_package()
. Um módulo é determinado como um pacote se seu caminho de arquivo (conforme fornecido porExecutionLoader.get_filename()
) for um arquivo chamado__init__
quando a extensão do arquivo for removida e o nome do módulo em si não terminar em__init__
.
- class importlib.abc.ResourceReader¶
Substituída por TraversableResources
Uma classe base abstrata para fornecer a capacidade de ler recursos.
Da perspectiva deste ABC, um recurso é um artefato binário que é enviado dentro de um pacote. Normalmente isso é algo como um arquivo de dados que fica próximo ao arquivo
__init__.py
do pacote. O objetivo desta classe é ajudar a abstrair o acesso a tais arquivos de dados para que não importe se o pacote e seu(s) arquivo(s) de dados estão armazenados, por exemplo, em um arquivo zip versus no sistema de arquivos.Para qualquer um dos métodos desta classe, espera-se que o argumento resource seja um objeto caminho ou similar que representa conceitualmente apenas um nome de arquivo. Isso significa que nenhum caminho de subdiretório deve ser incluído no argumento resource. Isso ocorre porque a localização do pacote para o qual o leitor se destina, atua como o “diretório”. Portanto, a metáfora para diretórios e nomes de arquivos são pacotes e recursos, respectivamente. É também por isso que se espera que as instâncias dessa classe se correlacionem diretamente a um pacote específico (em vez de representar potencialmente vários pacotes ou um módulo).
Carregadores que desejam oferecer suporte à leitura de recursos devem fornecer um método chamado
get_resource_reader(nomecompleto)
que retorna um objeto implementando esta interface ABC. Se o módulo especificado por nomecompleto não for um pacote, este método deve retornarNone
. Um objeto compatível com este ABC só deve ser retornado quando o módulo especificado for um pacote.Adicionado na versão 3.7.
Deprecated since version 3.12, removed in version 3.14: Use
importlib.resources.abc.TraversableResources
.- abstractmethod open_resource(resource)¶
Retorna um objeto arquivo ou similar aberto para leitura binária de resource.
Se o recurso não puder ser encontrado,
FileNotFoundError
é levantada.
- abstractmethod resource_path(resource)¶
Retorna o caminho do sistema de arquivos para resource.
Se o recurso não existir concretamente no sistema de arquivos, levanta
FileNotFoundError
.
- abstractmethod is_resource(name)¶
Retorna
True
se o name nomeado for considerado um recurso.FileNotFoundError
é levantada se name não existir.
- abstractmethod contents()¶
Retorna um iterável de strings sobre o conteúdo do pacote. Observe que não é necessário que todos os nomes retornados pelo iterador sejam recursos reais, por exemplo, é aceitável retornar nomes para os quais
is_resource()
seria falso.Permitir que nomes que não são recursos sejam retornados é permitir situações em que a forma como um pacote e seus recursos são armazenados é conhecida a priori e os nomes que não são recursos seriam úteis. Por exemplo, o retorno de nomes de subdiretórios é permitido para que, quando se souber que o pacote e os recursos estão armazenados no sistema de arquivos, esses nomes de subdiretórios possam ser usados diretamente.
O método abstrato retorna um iterável sem itens.
- class importlib.abc.Traversable¶
Um objeto com um subconjunto de métodos de
pathlib.Path
adequados para percorrer diretórios e abrir arquivos.Para uma representação do objeto no sistema de arquivos, use
importlib.resources.as_file()
.Adicionado na versão 3.9.
Deprecated since version 3.12, removed in version 3.14: Use
importlib.resources.abc.Traversable
.- name¶
Abstrato. O nome base deste objeto sem nenhuma referência pai.
- abstractmethod iterdir()¶
Produz objetos
Traversable
emself
.
- abstractmethod is_dir()¶
Retorna
True
seself
for um diretório.
- abstractmethod is_file()¶
Retorna
True
seself
for um arquivo.
- abstractmethod joinpath(child)¶
Retorna o filho Traversable em
self
.
- abstractmethod __truediv__(child)¶
Retorna o filho
Traversable
emself
.
- abstractmethod open(mode='r', *args, **kwargs)¶
mode pode ser ‘r’ ou ‘rb’ para abrir como texto ou binário. Retorna um manipulador adequado para leitura (o mesmo que
pathlib.Path.open
).Ao abrir como texto, aceita parâmetros de codificação como os aceitos por
io.TextIOWrapper
.
- read_bytes()¶
Lê o conteúdo de
self
como bytes.
- read_text(encoding=None)¶
Lê o conteúdo de
self
como texto.
- class importlib.abc.TraversableResources¶
Uma classe base abstrata para leitores de recursos capaz de servir a interface
importlib.resources.files()
. Subclasseimportlib.resources.abc.ResourceReader
e fornece implementações concretas dos métodos abstratos deimportlib.resources.abc.ResourceReader
. Portanto, qualquer carregador que forneçaimportlib.abc.TraversableResources
também fornece ResourceReader.Espera-se que os carregadores que desejam oferecer suporte à leitura de recursos implementem essa interface.
Adicionado na versão 3.9.
Deprecated since version 3.12, removed in version 3.14: Use
importlib.resources.abc.TraversableResources
.- abstractmethod files()¶
Retorna um objeto
importlib.resources.abc.Traversable
para o pacote carregado.
importlib.machinery
– Importadores e ganchos de caminho¶
Código-fonte: Lib/importlib/machinery.py
Este módulo contém vários objetos que ajudam o import
a localizar e carregar módulos.
- importlib.machinery.SOURCE_SUFFIXES¶
Uma lista de strings representando os sufixos de arquivo reconhecidos para módulos em código-fonte.
Adicionado na versão 3.3.
- importlib.machinery.DEBUG_BYTECODE_SUFFIXES¶
Uma lista de strings representando os sufixos de arquivo para módulos em bytecode não otimizado.
Adicionado na versão 3.3.
Obsoleto desde a versão 3.5: Use
BYTECODE_SUFFIXES
.
- importlib.machinery.OPTIMIZED_BYTECODE_SUFFIXES¶
Uma lista de strings representando os sufixos de arquivo para módulos em bytecode otimizado.
Adicionado na versão 3.3.
Obsoleto desde a versão 3.5: Use
BYTECODE_SUFFIXES
.
- importlib.machinery.BYTECODE_SUFFIXES¶
Uma lista de strings representando os sufixos de arquivo reconhecidos para módulos em bytecode (incluindo com ponto no início).
Adicionado na versão 3.3.
Alterado na versão 3.5: O valor não mais depende de
__debug__
.
- importlib.machinery.EXTENSION_SUFFIXES¶
Uma lista de strings representando os sufixos de arquivo reconhecidos para módulos de extensão.
Adicionado na versão 3.3.
- importlib.machinery.all_suffixes()¶
Retorna uma lista combinada de strings representando todos os sufixos de arquivo para módulos reconhecidos pelo maquinário de importação padrão. Este é um auxiliar para código que simplesmente precisa saber se um caminho de sistema de arquivos potencialmente se refere a um módulo sem precisar de detalhes sobre o tipo de módulo (por exemplo,
inspect.getmodulename()
).Adicionado na versão 3.3.
- class importlib.machinery.BuiltinImporter¶
Um importador para módulos embutidos. Todos os módulos embutidos conhecidos estão listados em
sys.builtin_module_names
. Esta classe implementa os ABCsimportlib.abc.MetaPathFinder
eimportlib.abc.InspectLoader
.Somente métodos de classe são definidos por esta classe para aliviar a necessidade de instanciação.
Alterado na versão 3.5: Como parte da PEP 489, o importador embutido agora implementa
Loader.create_module()
eLoader.exec_module()
- class importlib.machinery.FrozenImporter¶
Um importador para módulos congelados. Esta classe implementa os ABCs
importlib.abc.MetaPathFinder
eimportlib.abc.InspectLoader
.Somente métodos de classe são definidos por esta classe para aliviar a necessidade de instanciação.
Alterado na versão 3.4: Ganhou os métodos
create_module()
eexec_module()
.
- class importlib.machinery.WindowsRegistryFinder¶
Localizador para módulos declarados no registro do Windows. Esta classe implementa a ABC
importlib.abc.MetaPathFinder
.Somente métodos de classe são definidos por esta classe para aliviar a necessidade de instanciação.
Adicionado na versão 3.3.
Obsoleto desde a versão 3.6: Use a configuração de
site
em vez disso. Versões futuras do Python podem não habilitar esse localizador por padrão.
- class importlib.machinery.PathFinder¶
Um Localizador para atributos
sys.path
e pacote__path__
. Esta classe implementa a ABCimportlib.abc.MetaPathFinder
.Somente métodos de classe são definidos por esta classe para aliviar a necessidade de instanciação.
- classmethod find_spec(fullname, path=None, target=None)¶
Método de classe que tenta encontrar um spec para o módulo especificado por fullname em
sys.path
ou, se definido, em path. Para cada entrada de caminho pesquisada,sys.path_importer_cache
é verificado. Se um objeto não falso for encontrado, ele será usado como o localizador de entrada de caminho para procurar o módulo que está sendo pesquisado. Se nenhuma entrada for encontrada emsys.path_importer_cache
, entãosys.path_hooks
será pesquisado para um localizador para a entrada de caminho e, se encontrado, será armazenado emsys.path_importer_cache
junto com a consulta sobre o módulo. Se nenhum localizador for encontrado, entãoNone
será armazenado no cache e retornado.Adicionado na versão 3.4.
Alterado na versão 3.5: Se o diretório de trabalho atual — representado por uma string vazia — não for mais válido,
None
será retornado, mas nenhum valor será armazenado em cache emsys.path_importer_cache
.
- classmethod invalidate_caches()¶
Chama
importlib.abc.PathEntryFinder.invalidate_caches()
em todos os localizadores armazenados emsys.path_importer_cache
que definem o método. Caso contrário, as entradas emsys.path_importer_cache
definidas comoNone
são excluídas.Alterado na versão 3.7: Entradas de
None
emsys.path_importer_cache
são excluídas.
Alterado na versão 3.4: Chama objetos em
sys.path_hooks
com o diretório de trabalho atual para''
(ou seja, a string vazia).
- class importlib.machinery.FileFinder(path, *loader_details)¶
Uma implementação concreta de
importlib.abc.PathEntryFinder
que armazena em cache os resultados do sistema de arquivos.O argumento path é o diretório que o localizador é responsável por pesquisar.
O argumento loader_details é um número variável de tuplas de 2 itens, cada uma contendo um carregador e uma sequência de sufixos de arquivo que o carregador reconhece. Espera-se que os carregadores sejam chamáveis que aceitam dois argumentos do nome do módulo e o caminho para o arquivo encontrado.
O localizador armazenará em cache o conteúdo do diretório conforme necessário, fazendo chamadas de “stat” para cada pesquisa de módulo para verificar se o cache não está desatualizado. Como a obsolescência do cache depende da granularidade das informações de estado do sistema operacional do sistema de arquivos, há uma condição de corrida potencial de busca por um módulo, criação de um novo arquivo e, em seguida, busca pelo módulo que o novo arquivo representa. Se as operações ocorrerem rápido o suficiente para caber na granularidade das chamadas de “stat”, a pesquisa do módulo falhará. Para evitar que isso aconteça, ao criar um módulo dinamicamente, certifique-se de chamar
importlib.invalidate_caches()
.Adicionado na versão 3.3.
- path¶
O caminho que o localizador irá procurar.
- find_spec(fullname, target=None)¶
Tenta encontrar a especificação para manipular fullname dentro de
path
.Adicionado na versão 3.4.
- invalidate_caches()¶
Limpa o cache interno.
- classmethod path_hook(*loader_details)¶
Um método de classe que retorna uma clausura para uso em
sys.path_hooks
. Uma instância deFileFinder
é retornada pela clausura usando o argumento de caminho dado à clausura diretamente e loader_details indiretamente.Se o argumento para a clausura não for um diretório existente,
ImportError
será levantada.
- class importlib.machinery.SourceFileLoader(fullname, path)¶
Uma implementação concreta de
importlib.abc.SourceLoader
subclassificandoimportlib.abc.FileLoader
e fornecendo algumas implementações concretas de outros métodos.Adicionado na versão 3.3.
- name¶
O nome do módulo que este carregador irá manipular.
- path¶
O caminho para o arquivo fonte.
- path_stats(path)¶
Implementação concreta de
importlib.abc.SourceLoader.path_stats()
.
- set_data(path, data)¶
Implementação concreta de
importlib.abc.SourceLoader.set_data()
.
- load_module(name=None)¶
Implementação concreta de
importlib.abc.Loader.load_module()
onde a especificação do nome do módulo para carregar é opcionalObsoleto desde a versão 3.6: Use
importlib.abc.Loader.exec_module()
.
- class importlib.machinery.SourcelessFileLoader(fullname, path)¶
Uma implementação concreta de
importlib.abc.FileLoader
que pode importar arquivos de bytecode (ou seja, não existem arquivos de código-fonte).Observe que o uso direto de arquivos de bytecode (e, portanto, não de arquivos de código-fonte) impede que seus módulos sejam utilizáveis por todas as implementações do Python ou novas versões do Python que alteram o formato do bytecode.
Adicionado na versão 3.3.
- name¶
O nome do módulo que o carregador vai manipular.
- path¶
O caminho para o arquivo de bytecode.
- get_source(fullname)¶
Retorna
None
, pois os arquivos de bytecode não têm código-fonte quando este carregador é usado.
- load_module(name=None)¶
Implementação concreta de
importlib.abc.Loader.load_module()
onde a especificação do nome do módulo para carregar é opcionalObsoleto desde a versão 3.6: Use
importlib.abc.Loader.exec_module()
.
- class importlib.machinery.ExtensionFileLoader(fullname, path)¶
Uma implementação concreta de
importlib.abc.ExecutionLoader
para módulos de extensão.O argumento fullname especifica o nome do módulo ao qual o carregador deve dar suporte. O argumento path é o caminho para o arquivo do módulo de extensão.
Observe que, por padrão, a importação de um módulo de extensão falhará em subinterpretadores se ele não implementar inicialização multifásica (consulte a PEP 489), mesmo que ele seja importado com sucesso.
Adicionado na versão 3.3.
Alterado na versão 3.12: A inicialização multifásica agora é necessária para uso em subinterpretadores.
- name¶
Nome do módulo ao qual o carregador dá suporte.
- path¶
Caminho para o módulo de extensão.
- create_module(spec)¶
Cria o objeto do módulo a partir da especificação fornecida de acordo com a PEP 489.
Adicionado na versão 3.5.
- exec_module(module)¶
Inicializa o objeto do módulo fornecido de acordo com a PEP 489.
Adicionado na versão 3.5.
- is_package(fullname)¶
Retorna
True
se o caminho do arquivo aponta para o módulo__init__
de um pacote com base emEXTENSION_SUFFIXES
.
- get_code(fullname)¶
Retorna
None
, pois os módulos de extensão não possuem um objeto código.
- get_source(fullname)¶
Retorna
None
pois os módulos de extensão não possuem código-fonte.
- class importlib.machinery.NamespaceLoader(name, path, path_finder)¶
Uma implementação concreta de
importlib.abc.InspectLoader
para pacotes de espaço de nomes. Este é um apelido para uma classe privada e só é tornado público para introspecção do atributo__loader__
em pacotes de espaço de nomes:>>> from importlib.machinery import NamespaceLoader >>> import my_namespace >>> isinstance(my_namespace.__loader__, NamespaceLoader) True >>> import importlib.abc >>> isinstance(my_namespace.__loader__, importlib.abc.Loader) True
Adicionado na versão 3.11.
- class importlib.machinery.ModuleSpec(name, loader, *, origin=None, loader_state=None, is_package=None)¶
A specification for a module’s import-system-related state. This is typically exposed as the module’s
__spec__
attribute. Many of these attributes are also available directly on a module: for example,module.__spec__.origin == module.__file__
. Note, however, that while the values are usually equivalent, they can differ since there is no synchronization between the two objects. For example, it is possible to update the module’s__file__
at runtime and this will not be automatically reflected in the module’s__spec__.origin
, and vice versa.Adicionado na versão 3.4.
- name¶
The module’s fully qualified name (see
module.__name__
). The finder should always set this attribute to a non-empty string.
- loader¶
The loader used to load the module (see
module.__loader__
). The finder should always set this attribute.
- origin¶
The location the loader should use to load the module (see
module.__file__
). For example, for modules loaded from a.py
file this is the filename. The finder should always set this attribute to a meaningful value for the loader to use. In the uncommon case that there is not one (like for namespace packages), it should be set toNone
.
- submodule_search_locations¶
A (possibly empty) sequence of strings enumerating the locations in which a package’s submodules will be found (see
module.__path__
). Most of the time there will only be a single directory in this list.The finder should set this attribute to a sequence, even an empty one, to indicate to the import system that the module is a package. It should be set to
None
for non-package modules. It is set automatically later to a special object for namespace packages.
- loader_state¶
The finder may set this attribute to an object containing additional, module-specific data to use when loading the module. Otherwise it should be set to
None
.
- cached¶
The filename of a compiled version of the module’s code (see
module.__cached__
). The finder should always set this attribute but it may beNone
for modules that do not need compiled code stored.
- parent¶
(Read-only) The fully qualified name of the package the module is in (or the empty string for a top-level module). See
module.__package__
. If the module is a package then this is the same asname
.
- class importlib.machinery.AppleFrameworkLoader(name, path)¶
A specialization of
importlib.machinery.ExtensionFileLoader
that is able to load extension modules in Framework format.For compatibility with the iOS App Store, all binary modules in an iOS app must be dynamic libraries, contained in a framework with appropriate metadata, stored in the
Frameworks
folder of the packaged app. There can be only a single binary per framework, and there can be no executable binary material outside the Frameworks folder.To accommodate this requirement, when running on iOS, extension module binaries are not packaged as
.so
files onsys.path
, but as individual standalone frameworks. To discover those frameworks, this loader is be registered against the.fwork
file extension, with a.fwork
file acting as a placeholder in the original location of the binary onsys.path
. The.fwork
file contains the path of the actual binary in theFrameworks
folder, relative to the app bundle. To allow for resolving a framework-packaged binary back to the original location, the framework is expected to contain a.origin
file that contains the location of the.fwork
file, relative to the app bundle.Por exemplo, considere o caso de uma importação
from foo.bar import _whiz
, onde_whiz
é implementado com o módulo bináriosources/foo/bar/_whiz.abi3.so
, comsources
sendo o local registrado emsys.path
, relativo ao pacote da aplicação. Este módulo deve ser distribuído comoFrameworks/foo.bar._whiz.framework/foo.bar._whiz
(criando o nome do framework a partir do caminho completo de importação do módulo), com um arquivoInfo.plist
no diretório.framework
identificando o binário como um framework. O módulofoo.bar._whiz
seria representado no local original com um arquivo marcadorsources/foo/bar/_whiz.abi3.fwork
, contendo o caminhoFrameworks/foo.bar._whiz/foo.bar._whiz
. O framework também conteriaFrameworks/foo.bar._whiz.framework/foo.bar._whiz.origin
, contendo o caminho para o arquivo.fwork
.When a module is loaded with this loader, the
__file__
for the module will report as the location of the.fwork
file. This allows code to use the__file__
of a module as an anchor for file system traversal. However, the spec origin will reference the location of the actual binary in the.framework
folder.The Xcode project building the app is responsible for converting any
.so
files from wherever they exist in thePYTHONPATH
into frameworks in theFrameworks
folder (including stripping extensions from the module file, the addition of framework metadata, and signing the resulting framework), and creating the.fwork
and.origin
files. This will usually be done with a build step in the Xcode project; see the iOS documentation for details on how to construct this build step.Adicionado na versão 3.13.
Disponibilidade
- name¶
Nome do módulo ao qual o carregador dá suporte.
- path¶
Path to the
.fwork
file for the extension module.
importlib.util
– Utility code for importers¶
Source code: Lib/importlib/util.py
This module contains the various objects that help in the construction of an importer.
- importlib.util.MAGIC_NUMBER¶
The bytes which represent the bytecode version number. If you need help with loading/writing bytecode then consider
importlib.abc.SourceLoader
.Adicionado na versão 3.4.
- importlib.util.cache_from_source(path, debug_override=None, *, optimization=None)¶
Return the PEP 3147/PEP 488 path to the byte-compiled file associated with the source path. For example, if path is
/foo/bar/baz.py
the return value would be/foo/bar/__pycache__/baz.cpython-32.pyc
for Python 3.2. Thecpython-32
string comes from the current magic tag (seeget_tag()
; ifsys.implementation.cache_tag
is not defined thenNotImplementedError
will be raised).The optimization parameter is used to specify the optimization level of the bytecode file. An empty string represents no optimization, so
/foo/bar/baz.py
with an optimization of''
will result in a bytecode path of/foo/bar/__pycache__/baz.cpython-32.pyc
.None
causes the interpreter’s optimization level to be used. Any other value’s string representation is used, so/foo/bar/baz.py
with an optimization of2
will lead to the bytecode path of/foo/bar/__pycache__/baz.cpython-32.opt-2.pyc
. The string representation of optimization can only be alphanumeric, elseValueError
is raised.The debug_override parameter is deprecated and can be used to override the system’s value for
__debug__
. ATrue
value is the equivalent of setting optimization to the empty string. AFalse
value is the same as setting optimization to1
. If both debug_override an optimization are notNone
thenTypeError
is raised.Adicionado na versão 3.4.
Alterado na versão 3.5: The optimization parameter was added and the debug_override parameter was deprecated.
Alterado na versão 3.6: Aceita um objeto caminho ou similar.
- importlib.util.source_from_cache(path)¶
Given the path to a PEP 3147 file name, return the associated source code file path. For example, if path is
/foo/bar/__pycache__/baz.cpython-32.pyc
the returned path would be/foo/bar/baz.py
. path need not exist, however if it does not conform to PEP 3147 or PEP 488 format, aValueError
is raised. Ifsys.implementation.cache_tag
is not defined,NotImplementedError
is raised.Adicionado na versão 3.4.
Alterado na versão 3.6: Aceita um objeto caminho ou similar.
- importlib.util.decode_source(source_bytes)¶
Decode the given bytes representing source code and return it as a string with universal newlines (as required by
importlib.abc.InspectLoader.get_source()
).Adicionado na versão 3.4.
- importlib.util.resolve_name(name, package)¶
Resolve a relative module name to an absolute one.
If name has no leading dots, then name is simply returned. This allows for usage such as
importlib.util.resolve_name('sys', __spec__.parent)
without doing a check to see if the package argument is needed.ImportError
is raised if name is a relative module name but package is a false value (e.g.None
or the empty string).ImportError
is also raised if a relative name would escape its containing package (e.g. requesting..bacon
from within thespam
package).Adicionado na versão 3.3.
Alterado na versão 3.9: To improve consistency with import statements, raise
ImportError
instead ofValueError
for invalid relative import attempts.
- importlib.util.find_spec(name, package=None)¶
Find the spec for a module, optionally relative to the specified package name. If the module is in
sys.modules
, thensys.modules[name].__spec__
is returned (unless the spec would beNone
or is not set, in which caseValueError
is raised). Otherwise a search usingsys.meta_path
is done.None
is returned if no spec is found.If name is for a submodule (contains a dot), the parent module is automatically imported.
name and package work the same as for
import_module()
.Adicionado na versão 3.4.
Alterado na versão 3.7: Raises
ModuleNotFoundError
instead ofAttributeError
if package is in fact not a package (i.e. lacks a__path__
attribute).
- importlib.util.module_from_spec(spec)¶
Create a new module based on spec and
spec.loader.create_module
.If
spec.loader.create_module
does not returnNone
, then any pre-existing attributes will not be reset. Also, noAttributeError
will be raised if triggered while accessing spec or setting an attribute on the module.This function is preferred over using
types.ModuleType
to create a new module as spec is used to set as many import-controlled attributes on the module as possible.Adicionado na versão 3.5.
- importlib.util.spec_from_loader(name, loader, *, origin=None, is_package=None)¶
A factory function for creating a
ModuleSpec
instance based on a loader. The parameters have the same meaning as they do for ModuleSpec. The function uses available loader APIs, such asInspectLoader.is_package()
, to fill in any missing information on the spec.Adicionado na versão 3.4.
- importlib.util.spec_from_file_location(name, location, *, loader=None, submodule_search_locations=None)¶
A factory function for creating a
ModuleSpec
instance based on the path to a file. Missing information will be filled in on the spec by making use of loader APIs and by the implication that the module will be file-based.Adicionado na versão 3.4.
Alterado na versão 3.6: Aceita um objeto caminho ou similar.
- importlib.util.source_hash(source_bytes)¶
Return the hash of source_bytes as bytes. A hash-based
.pyc
file embeds thesource_hash()
of the corresponding source file’s contents in its header.Adicionado na versão 3.7.
- importlib.util._incompatible_extension_module_restrictions(*, disable_check)¶
A context manager that can temporarily skip the compatibility check for extension modules. By default the check is enabled and will fail when a single-phase init module is imported in a subinterpreter. It will also fail for a multi-phase init module that doesn’t explicitly support a per-interpreter GIL, when imported in an interpreter with its own GIL.
Note that this function is meant to accommodate an unusual case; one which is likely to eventually go away. There’s is a pretty good chance this is not what you were looking for.
You can get the same effect as this function by implementing the basic interface of multi-phase init (PEP 489) and lying about support for multiple interpreters (or per-interpreter GIL).
Aviso
Using this function to disable the check can lead to unexpected behavior and even crashes. It should only be used during extension module development.
Adicionado na versão 3.12.
- class importlib.util.LazyLoader(loader)¶
A class which postpones the execution of the loader of a module until the module has an attribute accessed.
This class only works with loaders that define
exec_module()
as control over what module type is used for the module is required. For those same reasons, the loader’screate_module()
method must returnNone
or a type for which its__class__
attribute can be mutated along with not using slots. Finally, modules which substitute the object placed intosys.modules
will not work as there is no way to properly replace the module references throughout the interpreter safely;ValueError
is raised if such a substitution is detected.Nota
For projects where startup time is critical, this class allows for potentially minimizing the cost of loading a module if it is never used. For projects where startup time is not essential then use of this class is heavily discouraged due to error messages created during loading being postponed and thus occurring out of context.
Adicionado na versão 3.5.
Alterado na versão 3.6: Began calling
create_module()
, removing the compatibility warning forimportlib.machinery.BuiltinImporter
andimportlib.machinery.ExtensionFileLoader
.- classmethod factory(loader)¶
A class method which returns a callable that creates a lazy loader. This is meant to be used in situations where the loader is passed by class instead of by instance.
suffixes = importlib.machinery.SOURCE_SUFFIXES loader = importlib.machinery.SourceFileLoader lazy_loader = importlib.util.LazyLoader.factory(loader) finder = importlib.machinery.FileFinder(path, (lazy_loader, suffixes))
Exemplos¶
Importing programmatically¶
To programmatically import a module, use importlib.import_module()
.
import importlib
itertools = importlib.import_module('itertools')
Checando se o módulo pode ser importado¶
If you need to find out if a module can be imported without actually doing the
import, then you should use importlib.util.find_spec()
.
Note that if name
is a submodule (contains a dot),
importlib.util.find_spec()
will import the parent module.
import importlib.util
import sys
# For illustrative purposes.
name = 'itertools'
if name in sys.modules:
print(f"{name!r} already in sys.modules")
elif (spec := importlib.util.find_spec(name)) is not None:
# If you chose to perform the actual import ...
module = importlib.util.module_from_spec(spec)
sys.modules[name] = module
spec.loader.exec_module(module)
print(f"{name!r} has been imported")
else:
print(f"can't find the {name!r} module")
Importa o arquivo de origem diretamente¶
This recipe should be used with caution: it is an approximation of an import
statement where the file path is specified directly, rather than
sys.path
being searched. Alternatives should first be considered first,
such as modifying sys.path
when a proper module is required, or using
runpy.run_path()
when the global namespace resulting from running a Python
file is appropriate.
To import a Python source file directly from a path, use the following recipe:
import importlib.util
import sys
def import_from_path(module_name, file_path):
spec = importlib.util.spec_from_file_location(module_name, file_path)
module = importlib.util.module_from_spec(spec)
sys.modules[module_name] = module
spec.loader.exec_module(module)
return module
# For illustrative purposes only (use of `json` is arbitrary).
import json
file_path = json.__file__
module_name = json.__name__
# Similar outcome as `import json`.
json = import_from_path(module_name, file_path)
Implementing lazy imports¶
The example below shows how to implement lazy imports:
>>> import importlib.util
>>> import sys
>>> def lazy_import(name):
... spec = importlib.util.find_spec(name)
... loader = importlib.util.LazyLoader(spec.loader)
... spec.loader = loader
... module = importlib.util.module_from_spec(spec)
... sys.modules[name] = module
... loader.exec_module(module)
... return module
...
>>> lazy_typing = lazy_import("typing")
>>> #lazy_typing is a real module object,
>>> #but it is not loaded in memory yet.
>>> lazy_typing.TYPE_CHECKING
False
Setting up an importer¶
For deep customizations of import, you typically want to implement an
importer. This means managing both the finder and loader
side of things. For finders there are two flavours to choose from depending on
your needs: a meta path finder or a path entry finder. The
former is what you would put on sys.meta_path
while the latter is what
you create using a path entry hook on sys.path_hooks
which works
with sys.path
entries to potentially create a finder. This example will
show you how to register your own importers so that import will use them (for
creating an importer for yourself, read the documentation for the appropriate
classes defined within this package):
import importlib.machinery
import sys
# For illustrative purposes only.
SpamMetaPathFinder = importlib.machinery.PathFinder
SpamPathEntryFinder = importlib.machinery.FileFinder
loader_details = (importlib.machinery.SourceFileLoader,
importlib.machinery.SOURCE_SUFFIXES)
# Setting up a meta path finder.
# Make sure to put the finder in the proper location in the list in terms of
# priority.
sys.meta_path.append(SpamMetaPathFinder)
# Setting up a path entry finder.
# Make sure to put the path hook in the proper location in the list in terms
# of priority.
sys.path_hooks.append(SpamPathEntryFinder.path_hook(loader_details))
Approximating importlib.import_module()
¶
Import itself is implemented in Python code, making it possible to
expose most of the import machinery through importlib. The following
helps illustrate the various APIs that importlib exposes by providing an
approximate implementation of
importlib.import_module()
:
import importlib.util
import sys
def import_module(name, package=None):
"""An approximate implementation of import."""
absolute_name = importlib.util.resolve_name(name, package)
try:
return sys.modules[absolute_name]
except KeyError:
pass
path = None
if '.' in absolute_name:
parent_name, _, child_name = absolute_name.rpartition('.')
parent_module = import_module(parent_name)
path = parent_module.__spec__.submodule_search_locations
for finder in sys.meta_path:
spec = finder.find_spec(absolute_name, path)
if spec is not None:
break
else:
msg = f'No module named {absolute_name!r}'
raise ModuleNotFoundError(msg, name=absolute_name)
module = importlib.util.module_from_spec(spec)
sys.modules[absolute_name] = module
spec.loader.exec_module(module)
if path is not None:
setattr(parent_module, child_name, module)
return module