poza błędem pakietu najwyższego poziomu podczas importu względnego

Wygląda na to, że jest już sporo pytań na temat względnego importu w Pythonie 3, ale po przejściu wielu z nich nadal nie znalazłem odpowiedzi na mój problem. więc oto pytanie.

Mam pakiet pokazany poniżej

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

i mam jedną linię w test.py:

from ..A import foo

teraz jestem w folderze packagei biegam

python -m test_A.test

Dostałem wiadomość

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

ale jeśli jestem w folderze nadrzędnym packagenp. uruchamiam:

cd ..
python -m package.test_A.test

wszystko w porządku.

Teraz moje pytanie brzmi: kiedy jestem w folderze packagei uruchamiam moduł w sub-pakiecie test_A, ponieważ test_A.test, zgodnie z moim zrozumieniem, ..Aidzie tylko o jeden poziom, który wciąż znajduje się w packagefolderze, dlaczego wyświetla komunikat beyond top-level package. Jaki jest dokładnie powód, który powoduje ten komunikat o błędzie?

EDYCJA: Istnieją lepsze / bardziej spójne odpowiedzi na to pytanie w innych pytaniach:

• Import pakietów rodzeństwa
• Względny import po raz miliardowy

Dlaczego to nie działa? Jest tak, ponieważ python nie rejestruje, skąd pakiet został załadowany. Więc kiedy to zrobisz python -m test_A.test, po prostu odrzuca wiedzę, która test_A.testjest faktycznie przechowywana package(tzn. packageNie jest uważana za pakiet). Próba from ..A import foodostępu do informacji, których już nie ma (tj. Katalogów rodzeństwa załadowanej lokalizacji). Jest to koncepcyjnie podobne do zezwalania from ..os import pathna plik w math. Byłoby to złe, ponieważ chcesz, aby pakiety były odrębne. Jeśli muszą użyć czegoś z innego pakietu, powinni odwołać się do nich globalnie za pomocą from os import pathi pozwolić pythonowi sprawdzić, gdzie to jest za pomocą $PATHi $PYTHONPATH.

Kiedy używasz python -m package.test_A.test, wtedy używanie from ..A import foorozwiązuje się dobrze, ponieważ śledziło to, co jest w packageśrodku, a ty po prostu uzyskujesz dostęp do katalogu potomnego załadowanej lokalizacji.

Dlaczego Python nie uważa bieżącego katalogu roboczego za pakiet? Bez pojęcia , ale Boże, byłoby to użyteczne.

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

Spróbuj tego. Pracował dla mnie.

Założenie:
jeśli jesteś w packagekatalogu Ai test_Ajesteś oddzielnym pakietem.

Wniosek:
..Aimport jest dozwolony tylko w pakiecie.

Dalsze uwagi:
Udostępnianie względnych importów tylko w pakietach jest przydatne, jeśli chcesz wymusić umieszczenie pakietów na dowolnej ścieżce sys.path.

EDYTOWAĆ:

Czy jestem jedynym, który uważa, że ​​to szalone !? Dlaczego na świecie obecny katalog roboczy nie jest uważany za pakiet? - Multihunter

Bieżący katalog roboczy zwykle znajduje się w sys.path. Wszystkie pliki można więc importować. Jest to zachowanie od Python 2, gdy pakiety jeszcze nie istniały. Utworzenie działającego katalogu jako pakietu pozwoliłoby na import modułów jako „import .A” i „import A”, które wówczas byłyby dwoma różnymi modułami. Być może jest to niekonsekwencja do rozważenia.

Żadne z tych rozwiązań nie działało dla mnie w wersji 3.6, ze strukturą folderów taką jak:

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

Moim celem było zaimportowanie z modułu 1 do modułu 2. Dziwne, co w końcu dla mnie zadziałało:

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

Zwróć uwagę na pojedynczą kropkę w przeciwieństwie do wspomnianych dotychczas rozwiązań z dwiema kropkami.

Edycja: Poniższe pomogło mi to wyjaśnić:

import os
print (os.getcwd())

W moim przypadku katalog roboczy był (nieoczekiwanie) katalogiem głównym projektu.

from package.A import foo

Myślę, że to jest jaśniejsze niż

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

Jak sugeruje najbardziej popularna odpowiedź, w zasadzie dlatego, że twoja PYTHONPATHlub sys.pathzawiera .twoją ścieżkę do pakietu. A względny import jest związany z bieżącym katalogiem roboczym, a nie plikiem, w którym odbywa się import; dziwnie.

Możesz to naprawić, najpierw zmieniając import względny na absolutny, a następnie zaczynając od:

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

LUB wymuszanie ścieżki Pythona podczas wywoływania w ten sposób, ponieważ:

Podczas python -m test_A.testwykonywania za test_A/test.pypomocą __name__ == '__main__'i__file__ == '/absolute/path/to/test_A/test.py'

Oznacza to, że test.pymożesz użyć swojego absolutnie importczęściowo chronionego w głównym przypadku, a także wykonać jednorazową manipulację ścieżką w Pythonie:

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())

Edytuj: 2020-05-08: Wygląda na to, że strona, którą cytowałem, nie jest już kontrolowana przez osobę, która napisała poradę, więc usuwam link do strony. Dzięki za poinformowanie mnie o baxx.

Jeśli ktoś wciąż ma problemy z uzyskaniem już świetnych odpowiedzi, znalazłem porady na stronie, która nie jest już dostępna.

Niezbędny cytat ze strony, o której wspomniałem:

„To samo można określić programowo w następujący sposób:

import sys

sys.path.append ('..')

Oczywiście powyższy kod musi zostać napisany przed drugą instrukcją importu .

To oczywiste, że tak musi być, myśląc o tym po fakcie. Próbowałem użyć sys.path.append ('..') w moich testach, ale natknąłem się na problem opublikowany przez OP. Dodając definicję importu i sys.path przed innymi importami, udało mi się rozwiązać problem.

jeśli masz __init__.pyw górnym folderze, możesz zainicjować import jak import file/path as aliasw tym pliku inicjującym. Następnie możesz użyć go na niższych skryptach jako:

import alias

Moim skromnym zdaniem rozumiem to pytanie w następujący sposób:

[PRZYPADEK 1] Po rozpoczęciu importu bezwzględnego, takiego jak

python -m test_A.test

lub

import test_A.test

lub

from test_A import test

tak naprawdę ustawiasz kotwicę importu na test_A, innymi słowy, pakiet najwyższego poziomu to test_A. Tak więc, gdy mamy test.py from ..A import xxx, uciekasz od kotwicy, a Python nie pozwala na to.

[PRZYPADEK 2] Kiedy to zrobisz

python -m package.test_A.test

lub

from package.test_A import test

Twój kotwica staje się packagetak package/test_A/test.pyrobić from ..A import xxxnie uciec kotwicę (nadal wewnątrz packagefolderu), a Python szczęśliwie akceptuje to.

W skrócie:

• Import bezwzględny zmienia bieżącą kotwicę (= redefiniuje, co to jest pakiet najwyższego poziomu);
• Import względny nie zmienia kotwicy, ale ogranicza się do niej.

Ponadto możemy użyć pełnej nazwy modułu (FQMN), aby sprawdzić ten problem.

Sprawdź FQMN w każdym przypadku:

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

Tak więc, w przypadku CASE2, powstanie from .. import xxxnowy moduł z FQMN = package.xxx, co jest dopuszczalne.

Podczas gdy w przypadku CASE1, ..od wewnątrz from .. import xxxwyskoczy z węzła początkowego (kotwicy) test_Ai NIE jest to dozwolone przez Python.

Nie jestem pewien w Pythonie 2.x, ale w Pythonie 3.6, zakładając, że próbujesz uruchomić cały pakiet, wystarczy użyć -t

-t, --top-level-directory katalog Katalog najwyższego poziomu projektu (domyślnie katalog startowy)

Na takiej strukturze

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

Można na przykład użyć:

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

I nadal importuj my_module.my_classbez większych dramatów.