além do erro do pacote de nível superior na importação relativa

Parece que já existem algumas perguntas aqui sobre a importação relativa no python 3, mas depois de passar por muitas delas, ainda não encontrei a resposta para o meu problema. Então aqui está a questão.

Eu tenho um pacote mostrado abaixo

package/
   __init__.py
   A/
      __init__.py
      foo.py
   test_A/
      __init__.py
      test.py

e eu tenho uma única linha no test.py:

from ..A import foo

agora, estou na pasta de packagee corro

python -m test_A.test

Eu recebi mensagem

"ValueError: attempted relative import beyond top-level package"

mas se eu estiver na pasta pai de package, por exemplo, eu corro:

cd ..
python -m package.test_A.test

tudo está bem.

Agora, minha pergunta é: quando estou na pasta de packagee executo o módulo dentro do subpacote test_A test_A.test, pois , com base no meu entendimento, ..Asobe apenas um nível, que ainda está dentro da packagepasta, por que ele diz uma mensagem beyond top-level package. Qual é exatamente o motivo que causa essa mensagem de erro?

EDIT: Existem respostas melhores / mais coerentes para esta pergunta em outras perguntas:

• Importação de pacotes irmãos
• Importações relativas pela bilionésima vez

Por que isso não funciona? É porque o python não registra de onde um pacote foi carregado. Então, quando você o faz python -m test_A.test, basicamente apenas descarta o conhecimento que test_A.testestá realmente armazenado package(isto packageé, não é considerado um pacote). Tentativa de from ..A import footentar acessar informações que não possuem mais (por exemplo, diretórios irmãos de um local carregado). É conceitualmente semelhante a permitir a entrada from ..os import pathde um arquivo math. Isso seria ruim porque você deseja que os pacotes sejam distintos. Se eles precisam usar algo de outro pacote, eles devem se referir a eles globalmente com from os import pathe deixar o python descobrir onde está $PATHe $PYTHONPATH.

Quando você usa python -m package.test_A.test, o uso de from ..A import fooresolve é muito bom, porque ele acompanha o conteúdo packagee você está acessando um diretório filho de um local carregado.

Por que o python não considera o diretório de trabalho atual um pacote? Sem pistas , mas caramba, seria útil.

import sys
sys.path.append("..") # Adds higher directory to python modules path.

Tente isso. Trabalhou para mim.

Suposição:
se você estiver no packagediretório Ae test_Afor pacotes separados.

Conclusão: as
..Aimportações são permitidas apenas dentro de um pacote.

Observações adicionais:
Tornar as importações relativas disponíveis apenas nos pacotes é útil se você deseja forçar que os pacotes possam ser colocados em qualquer caminho localizado em sys.path.

EDITAR:

Eu sou o único que acha que isso é loucura !? Por que no mundo o diretório de trabalho atual não é considerado um pacote? - Multihunter

O diretório de trabalho atual geralmente está localizado em sys.path. Portanto, todos os arquivos são importáveis. Esse é um comportamento desde o Python 2, quando os pacotes ainda não existiam. Tornar o diretório em execução um pacote permitiria a importação de módulos como "import .A" e "import A", que seriam dois módulos diferentes. Talvez seja uma inconsistência a considerar.

Nenhuma dessas soluções funcionou para mim na 3.6, com uma estrutura de pastas como:

package1/
    subpackage1/
        module1.py
package2/
    subpackage2/
        module2.py

Meu objetivo era importar do módulo1 para o módulo2. O que finalmente funcionou para mim foi, curiosamente:

import sys
sys.path.append(".")

Observe o ponto único em oposição às soluções de dois pontos mencionadas até agora.

Edit: O seguinte ajudou a esclarecer isso para mim:

import os
print (os.getcwd())

No meu caso, o diretório de trabalho foi (inesperadamente) a raiz do projeto.

from package.A import foo

Eu acho que é mais claro do que

import sys
sys.path.append("..")

Como sugere a resposta mais popular, basicamente é porque você PYTHONPATHou sys.pathinclui, .mas não o caminho, para o seu pacote. E a importação relativa é relativa ao seu diretório de trabalho atual, não ao arquivo em que a importação ocorre; estranhamente.

Você pode corrigir isso alterando primeiro sua importação relativa para absoluta e, em seguida, iniciando-a com:

PYTHONPATH=/path/to/package python -m test_A.test

OU forçando o caminho python quando chamado dessa maneira, porque:

Com python -m test_A.testvocê está executando test_A/test.pycom __name__ == '__main__'e__file__ == '/absolute/path/to/test_A/test.py'

Isso significa que test.pyvocê pode usar seu absoluto importsemiprotegido na condição de caso principal e também fazer alguma manipulação de caminho Python única:

from os import path
…
def main():
…
if __name__ == '__main__':
    import sys
    sys.path.append(path.join(path.dirname(__file__), '..'))
    from A import foo

    exit(main())

Edit: 2020-05-08: Parece que o site que citei não é mais controlado pela pessoa que escreveu o conselho, por isso estou removendo o link para o site. Obrigado por me avisar baxx.

Se alguém ainda está lutando um pouco após as ótimas respostas já fornecidas, encontrei conselhos em um site que não está mais disponível.

Citação essencial do site que mencionei:

"O mesmo pode ser especificado programaticamente desta maneira:

sys de importação

sys.path.append ('..')

Obviamente, o código acima deve ser escrito antes da outra declaração de importação .

É bastante óbvio que tem que ser assim, pensando nisso depois do fato. Eu estava tentando usar o sys.path.append ('..') nos meus testes, mas me deparei com o problema postado pelo OP. Ao adicionar a definição import e sys.path antes das minhas outras importações, consegui resolver o problema.

se você tiver um __init__.pyem uma pasta superior, poderá inicializar a importação como import file/path as aliasnesse arquivo init. Então você pode usá-lo em scripts inferiores como:

import alias

Na minha humilde opinião, entendo esta questão da seguinte maneira:

[CASO 1] Quando você inicia uma importação absoluta como

python -m test_A.test

ou

import test_A.test

ou

from test_A import test

na verdade, você está configurando a âncora de importação como sendo test_A, em outras palavras, o pacote de nível superior test_A. Portanto, quando temos test.py do from ..A import xxx, você está escapando da âncora e o Python não permite isso.

[CASO 2] Quando você faz

python -m package.test_A.test

ou

from package.test_A import test

sua âncora se torna package, package/test_A/test.pyfazendo from ..A import xxxisso não escapa da âncora (ainda dentro da packagepasta) e o Python aceita isso com satisfação.

Em resumo:

• A importação absoluta altera a âncora atual (= redefine o que é o pacote de nível superior);
• A importação relativa não altera a âncora, mas restringe-se a ela.

Além disso, podemos usar o nome completo do módulo (FQMN) para inspecionar esse problema.

Verifique o FQMN em cada caso:

• [CASE2] test.__name__=package.test_A.test
• [CASE1] test.__name__=test_A.test

Portanto, para CASE2, um from .. import xxxresultará em um novo módulo com FQMN = package.xxx, que é aceitável.

Enquanto para CASE1, o ..de dentro from .. import xxxpulará do nó inicial (âncora) de test_A, e isso NÃO é permitido pelo Python.

Não tenho certeza no python 2.x, mas no python 3.6, supondo que você esteja tentando executar o conjunto inteiro, basta usar -t

Diretório de nível superior do projeto (o padrão é o diretório inicial)

Então, em uma estrutura como

project_root
  |
  |----- my_module
  |          \
  |           \_____ my_class.py
  |
  \ tests
      \___ test_my_func.py

Pode-se, por exemplo, usar:

python3 unittest discover -s /full_path/project_root/tests -t /full_path/project_root/

E ainda importe os my_module.my_classsem grandes dramas.