Względny import po raz miliardowy

To jest naprawdę problem w Pythonie. źródłem zamieszania jest to, że ludzie błędnie biorą względny import jako względną ścieżkę, która nie jest.

Na przykład gdy piszesz w faa.py :

from .. import foo

To ma znaczenie tylko wtedy, gdy .y został zidentyfikowany i załadowany przez Pythona, podczas wykonywania, jako część pakietu. W takim przypadku nazwa modułu dla faa.py będzie na przykład some_packagename.faa . Jeśli plik został załadowany tylko dlatego, że znajduje się w bieżącym katalogu, gdy python jest uruchomiony, jego nazwa nie odnosi się do żadnego pakietu i ostatecznie względny import nie powiedzie się.

Prostym rozwiązaniem, aby odwoływać się do modułów w bieżącym katalogu, jest użycie tego:

if __package__ is None or __package__ == '':
#uses current directory visibility
  import foo
else:
#uses current package visibility
  from . import foo

Oto ogólny przepis, zmodyfikowany tak, aby pasował jako przykład, który używam teraz do radzenia sobie z bibliotekami Pythona napisanymi jako pakiety, które zawierają współzależne pliki, gdzie chcę móc testować ich części fragmentarycznie. Nazwijmy to lib.foo i powiedzmy, że potrzebuje dostępu do lib.fileA dla funkcji f1 i f2 oraz lib.fileB dla klasy Class3.

Zawarłem kilka print wezwań, aby pomóc zilustrować, jak to działa. W praktyce chciałbyś je usunąć (a może również linia from __future__ import print_function).

Ten konkretny przykład jest zbyt prosty, aby pokazać, kiedy naprawdę musimy wstawić wpis do sys.path. (Zobacz odpowiedź Larsa Dla Przypadku, w którym potrzebujemy, gdy mamy dwa lub więcej poziomów katalogów pakietów, a następnie używamy os.path.dirname(os.path.dirname(__file__))-ale tak naprawdę nie boli tutaj też.) Jest również wystarczająco bezpieczny, aby zrobić to bez testu if _i in sys.path. Jeśli jednak każdy importowany plik wstawia tę samą ścieżkę-na przykład, jeśli zarówno fileA, jak i fileB chcą aby zaimportować narzędzia z pakietu - to zaśmieca sys.path tą samą ścieżką wiele razy, więc miło jest mieć if _i not in sys.path w kotle.

from __future__ import print_function # only when showing how this works

if __package__:
    print('Package named {!r}; __name__ is {!r}'.format(__package__, __name__))
    from .fileA import f1, f2
    from .fileB import Class3
else:
    print('Not a package; __name__ is {!r}'.format(__name__))
    # these next steps should be used only with care and if needed
    # (remove the sys.path manipulation for simple cases!)
    import os, sys
    _i = os.path.dirname(os.path.abspath(__file__))
    if _i not in sys.path:
        print('inserting {!r} into sys.path'.format(_i))
        sys.path.insert(0, _i)
    else:
        print('{!r} is already in sys.path'.format(_i))
    del _i # clean up global name space

    from fileA import f1, f2
    from fileB import Class3

... all the code as usual ...

if __name__ == '__main__':
    import doctest, sys
    ret = doctest.testmod()
    sys.exit(0 if ret.failed == 0 else 1)

Idea jest taka (i zauważ, że wszystkie te funkcje są takie same w python2. 7 i python 3.x):

1. Jeśli jest uruchamiany jako import lib lub from lib import foo jako zwykły import pakietów z zwykłego kodu, __package jest lib, A __name__ jest lib.foo. Wybieramy pierwszą ścieżkę kodu, importujemy z .fileA, itd.

2. If run as python lib/foo.py, __package__ będzie brak i {[26] } będzie __main__.

   Wybieramy drugą ścieżkę kodu. Katalog lib będzie już w sys.path, więc nie trzeba go dodawać. Importujemy z fileA, itp.

3. Jeśli jest uruchamiany w katalogu lib jako python foo.py, zachowanie jest takie samo jak w przypadku przypadku 2.

4. Jeśli jest uruchomiony w katalogu lib jako python -m foo, zachowanie jest podobne do przypadków 2 i 3. Jednak ścieżka do katalogu lib nie znajduje się w sys.path, więc dodaj go przed zaimportowaniem. To samo dotyczy Pythona, a następnie import foo.

   (od . jest w sys.path, tak naprawdę nie musimy dodawać absolutnej wersji ścieżki tutaj. To jest miejsce, w którym głębsza struktura zagnieżdżania pakietów, w którym chcemy to zrobić from ..otherlib.fileC import ..., robi różnicę. Jeśli tego nie robisz, możesz całkowicie pominąć całą manipulację sys.path.)

Uwagi

Jest jeszcze dziwactwo. Jeśli zaczniesz to wszystko od Na Zewnątrz:

$ python2 lib.foo

Lub:

$ python3 lib.foo

Zachowanie zależy od zawartości lib/__init__.py. Jeśli istnieje i jest puste, wszystko jest dobrze:

Package named 'lib'; __name__ is '__main__'

Ale jeśli lib/__init__.py sam importuje routine, aby mógł eksportować routine.name bezpośrednio jako lib.name, otrzymujesz:

$ python2 lib.foo
Package named 'lib'; __name__ is 'lib.foo'
Package named 'lib'; __name__ is '__main__'

Oznacza to, że moduł zostanie zaimportowany dwa razy, raz za pośrednictwem pakietu, a następnie ponownie jako __main__, aby uruchomić kod main. Python 3.6 i Później ostrzegają o tym:

$ python3 lib.routine
Package named 'lib'; __name__ is 'lib.foo'
[...]/runpy.py:125: RuntimeWarning: 'lib.foo' found in sys.modules
after import of package 'lib', but prior to execution of 'lib.foo';
this may result in unpredictable behaviour
  warn(RuntimeWarning(msg))
Package named 'lib'; __name__ is '__main__'

The Ostrzeżenie jest nowe, ale ostrzeżenie o zachowaniu nie jest. Jest to część tego, co niektórzy nazywają pułapką podwójnego importu. (Aby uzyskać dodatkowe informacje patrz wydanie 27487. Nick Coghlan says:

Ta Następna pułapka istnieje we wszystkich bieżących wersjach Pythona, w tym 3.3, i może być podsumowana w następujących ogólnych wytycznych: "nigdy nie dodawaj katalogu pakietu, ani żadnego katalogu wewnątrz pakietu, bezpośrednio do ścieżki Pythona".

Zauważ, że podczas gdy my naruszamy tę regułę, robimy to tylko, gdy ładowany plik jest , a nie jest ładowany jako część pakietu, a nasza modyfikacja jest specjalnie zaprojektowana, aby umożliwić nam dostęp do innych plików w tym pakiecie. (I, jak zauważyłam, prawdopodobnie nie powinniśmy tego robić w ogóle dla pakietów jednopoziomowych. Jeśli chcemy być extra-clean, możemy napisać to od nowa, np.:]}

    import os, sys
    _i = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
    if _i not in sys.path:
        sys.path.insert(0, _i)
    else:
        _i = None

    from sub.fileA import f1, f2
    from sub.fileB import Class3

    if _i:
        sys.path.remove(_i)
    del _i

Oznacza to, że modyfikujemy sys.path wystarczająco długo, aby osiągnąć nasz import, a następnie odkładamy go z powrotem tak, jak był (usunięcie jednej kopii _i wtedy i tylko wtedy, gdy dodaliśmy jedną kopię _i).

Oto jedno rozwiązanie, którego nie polecam, ale może być przydatne w niektórych sytuacjach, w których moduły po prostu nie zostały wygenerowane:

import os
import sys
parent_dir_name = os.path.dirname(os.path.dirname(os.path.realpath(__file__)))
sys.path.append(parent_dir_name + "/your_dir")
import your_script
your_script.a_function()

__name__ zmienia się w zależności od tego, czy dany kod jest uruchamiany w globalnej przestrzeni nazw, czy jako część zaimportowanego modułu.

Jeśli kod nie jest uruchomiony w przestrzeni globalnej, __name__ będzie nazwą modułu. Jeśli moduł działa w globalnej przestrzeni nazw-na przykład, jeśli wpiszesz go do konsoli lub uruchomisz moduł jako skrypt używając python.exe yourscriptnamehere.py, to __name__ staje się "__main__".

Zobaczysz wiele kodu Pythona z if __name__ == '__main__' jest używany do testowania, czy kod jest uruchamiany z globalnego przestrzeń nazw-która pozwala na posiadanie modułu, który służy jako skrypt.

Próbowałeś zrobić import z konsoli?

Miałem podobny problem, w którym nie chciałem zmieniać wyszukiwania modułu Pythona path i potrzebne do załadowania modułu relatywnie ze skryptu (pomimo "skrypty nie mogą importować relatywnie z wszystkimi" , jak brenbarn wyjaśnił ładnie powyżej).

Więc użyłem następujący hack. Niestety, opiera się na module imp, który stała się przestarzała od wersji 3.4, która została wycofana na rzecz importlib. (Czy jest to możliwe również z importlib? Nie wiem.) Mimo to hack działa na teraz.

Przykład dostępu do członków moduleX w subpackage1 ze skryptu znajdującego się w folderze subpackage2:

#!/usr/bin/env python3

import inspect
import imp
import os

def get_script_dir(follow_symlinks=True):
    """
    Return directory of code defining this very function.
    Should work from a module as well as from a script.
    """
    script_path = inspect.getabsfile(get_script_dir)
    if follow_symlinks:
        script_path = os.path.realpath(script_path)
    return os.path.dirname(script_path)

# loading the module (hack, relying on deprecated imp-module)
PARENT_PATH = os.path.dirname(get_script_dir())
(x_file, x_path, x_desc) = imp.find_module('moduleX', [PARENT_PATH+'/'+'subpackage1'])
module_x = imp.load_module('subpackage1.moduleX', x_file, x_path, x_desc)

# importing a function and a value
function = module_x.my_function
VALUE = module_x.MY_CONST

Czystszym podejściem wydaje się być modyfikacja sys.ścieżka używana do ładowania modułów, o której wspomniał Federico.

#!/usr/bin/env python3

if __name__ == '__main__' and __package__ is None:
    from os import sys, path
    # __file__ should be defined in this case
    PARENT_DIR = path.dirname(path.dirname(path.abspath(__file__)))
   sys.path.append(PARENT_DIR)
from subpackage1.moduleX import *

Więc po omówieniu tego wraz z wieloma innymi, natknąłem się na notatkę opublikowaną przez Doriana Bw tym artykule, która rozwiązała konkretny problem, który miałem, gdzie będę rozwijać moduły I klasy do użytku z usługą internetową, ale chcę również być w stanie przetestować je podczas kodowania, korzystając z udogodnień debuggera w PyCharm. Aby uruchomić testy w samodzielnej klasie, dodałbym na końcu pliku mojej klasy:

if __name__ == '__main__':
   # run test code here...

Ale gdybym chciał importować inne klasy lub moduły w tym samym folderze, musiałbym wtedy zmienić wszystkie moje polecenia import z notacji względnej NA odniesienia lokalne (tj. usunąć kropkę (.)) Ale po przeczytaniu sugestii Doriana, wypróbowałem jego "one-liner" i zadziałało! Mogę teraz testować w PyCharm i pozostawić mój kod testowy na miejscu, gdy używam klasy w innej klasie testowanej, lub gdy używam go w moim serwisie internetowym!

# import any site-lib modules first, then...
import sys
parent_module = sys.modules['.'.join(__name__.split('.')[:-1]) or '__main__']
if __name__ == '__main__' or parent_module.__name__ == '__main__':
    from codex import Codex # these are in same folder as module under test!
    from dblogger import DbLogger
else:
    from .codex import Codex
    from .dblogger import DbLogger

Instrukcja if sprawdza, czy uruchamiamy ten moduł jako main czy jest używany w innym module, który jest testowany jako main . Być może jest to oczywiste, ale oferuję tę notatkę tutaj na wypadek, gdyby ktoś inny sfrustrowany względnymi problemami z importem powyżej mógł z niej skorzystać.

Import względny używa atrybutu Nazwa modułu do określenia pozycji tego modułu w hierarchii pakietów. Jeśli nazwa modułu nie zawiera żadnych informacji o pakiecie (np. jest ustawiona na 'main'), to względne importowanie jest rozwiązywane tak, jakby moduł był modułem najwyższego poziomu, niezależnie od tego, gdzie moduł znajduje się w systemie plików.

Napisał mały pakiet Pythona do PyPi, który może pomóc widzom tego pytania. Pakiet działa jako obejście, jeśli jeden chce móc uruchamiać pliki Pythona zawierające importujące pakiety z górnego poziomu z pakietu / projektu bez bezpośredniego znajdowania się w katalogu importującego plik. https://pypi.org/project/import-anywhere/