Co właściwie robi from __future__ import absolute_import?

I odpowiedział na pytanie dotyczące bezwzględnych importu w Pythonie, i pomyślałem, zrozumiałem, na podstawie odczytu z Python 2.5 changelog i towarzyszące PEP . Jednak po zainstalowaniu Pythona 2.5 i próbie stworzenia przykładu prawidłowego użycia from __future__ import absolute_import, zdaję sobie sprawę, że sprawy nie są takie jasne.

Prosto z dziennika zmian połączonego powyżej, to stwierdzenie dokładnie podsumowało moje rozumienie absolutnej zmiany importu:

Powiedzmy, że masz taki katalog pakietów:

pkg/
pkg/__init__.py
pkg/main.py
pkg/string.py

Definiuje pakiet o nazwie pkgzawierający podmoduły pkg.maini pkg.string.

Rozważ kod w module main.py. Co się stanie, jeśli wykona instrukcję import string? W Pythonie 2.4 i wcześniejszych, najpierw zajrzy do katalogu pakietu, aby wykonać względny import, znajdzie pkg / string.py, zaimportuje zawartość tego pliku jako pkg.stringmoduł i ten moduł zostanie powiązany z nazwą "string"w pkg.mainprzestrzeni nazw modułu.

Stworzyłem więc dokładną strukturę katalogów:

$ ls -R
.:
pkg/

./pkg:
__init__.py  main.py  string.py

__init__.pyi string.pysą puste. main.pyzawiera następujący kod:

import string
print string.ascii_uppercase

Zgodnie z oczekiwaniami, uruchomienie tego w Pythonie 2.5 kończy się niepowodzeniem z AttributeError:

$ python2.5 pkg/main.py
Traceback (most recent call last):
  File "pkg/main.py", line 2, in <module>
    print string.ascii_uppercase
AttributeError: 'module' object has no attribute 'ascii_uppercase'

Jednak dalej w dzienniku zmian 2.5 znajdujemy to (podkreślenie dodane):

W Pythonie 2.5 możesz przełączyć importzachowanie na bezwzględne importowanie za pomocą from __future__ import absolute_importdyrektywy. To zachowanie importu absolutnego stanie się domyślnym w przyszłej wersji (prawdopodobnie Python 2.7). Gdy import bezwzględny jest domyślny, import stringzawsze znajdzie wersję biblioteki standardowej.

Stworzyłem w ten sposób pkg/main2.py, identyczny, main.pyale z dodatkową przyszłą dyrektywą importową. Teraz wygląda to tak:

from __future__ import absolute_import
import string
print string.ascii_uppercase

Jednak uruchomienie tego w Pythonie 2.5 ... kończy się niepowodzeniem z AttributeError:

$ python2.5 pkg/main2.py
Traceback (most recent call last):
  File "pkg/main2.py", line 3, in <module>
    print string.ascii_uppercase
AttributeError: 'module' object has no attribute 'ascii_uppercase'

To dość kategorycznie zaprzecza oświadczenie, że import stringbędzie zawsze znaleźć wersję STD-lib z włączonym import bezwzględne. Co więcej, pomimo ostrzeżenia, że ​​import absolutny ma stać się „nowym domyślnym” zachowaniem, napotkałem ten sam problem, używając zarówno Pythona 2.7, z __future__dyrektywą lub bez niej :

$ python2.7 pkg/main.py
Traceback (most recent call last):
  File "pkg/main.py", line 2, in <module>
    print string.ascii_uppercase
AttributeError: 'module' object has no attribute 'ascii_uppercase'

$ python2.7 pkg/main2.py
Traceback (most recent call last):
  File "pkg/main2.py", line 3, in <module>
    print string.ascii_uppercase
AttributeError: 'module' object has no attribute 'ascii_uppercase'

a także Python 3.5, z lub bez (zakładając zmianę printinstrukcji w obu plikach):

$ python3.5 pkg/main.py
Traceback (most recent call last):
  File "pkg/main.py", line 2, in <module>
    print(string.ascii_uppercase)
AttributeError: module 'string' has no attribute 'ascii_uppercase'

$ python3.5 pkg/main2.py
Traceback (most recent call last):
  File "pkg/main2.py", line 3, in <module>
    print(string.ascii_uppercase)
AttributeError: module 'string' has no attribute 'ascii_uppercase'

Przetestowałem inne odmiany tego. Zamiast string.pyJa stworzyłem pusty module - katalog o nazwie stringzawierającej tylko pusta __init__.py- i zamiast wydawania importu z main.pymam cd„d, aby pkgi uruchomić import bezpośrednio z REPL. Żadna z tych odmian (ani ich kombinacja) nie zmieniła powyższych wyników. Nie mogę tego pogodzić z tym, co przeczytałem o __future__dyrektywie i bezwzględnym imporcie.

Wydaje mi się, że można to łatwo wyjaśnić w następujący sposób (pochodzi z dokumentacji Pythona 2, ale ta instrukcja pozostaje niezmieniona w tych samych dokumentach dla Pythona 3):

sys.path

(...)

Zgodnie z inicjalizacją podczas uruchamiania programu, pierwszą pozycją na tej liście path[0]jest katalog zawierający skrypt, który został użyty do wywołania interpretera Pythona. Jeśli katalog skryptu nie jest dostępny (np. Jeśli interpreter jest wywoływany interaktywnie lub jeśli skrypt jest czytany ze standardowego wejścia), path[0]jest to pusty łańcuch, który kieruje Pythona do wyszukiwania modułów w bieżącym katalogu w pierwszej kolejności.

Więc czego mi brakuje? Dlaczego __future__stwierdzenie pozornie nie robi tego, co mówi, i jakie jest rozwiązanie tej sprzeczności między tymi dwoma rozdziałami dokumentacji, a także między opisanym a rzeczywistym zachowaniem?

Dziennik zmian jest niechlujnie sformułowany. from __future__ import absolute_importnie dba o to, czy coś jest częścią biblioteki standardowej i import stringnie zawsze daje moduł biblioteki standardowej z włączonymi bezwzględnymi importami.

from __future__ import absolute_importoznacza, że ​​jeśli ty import string, Python zawsze będzie szukał stringmodułu najwyższego poziomu , a nie current_package.string. Jednak nie wpływa to na logikę używaną przez Python do decydowania, który plik jest stringmodułem. Kiedy to zrobisz

python pkg/script.py

pkg/script.pynie wygląda jak część pakietu w Pythonie. Zgodnie z normalnymi procedurami pkgkatalog jest dodawany do ścieżki, a wszystkie .pypliki w pkgkatalogu wyglądają jak moduły najwyższego poziomu. import stringznajduje pkg/string.pynie dlatego, że wykonuje względny import, ale dlatego, że pkg/string.pywygląda na moduł najwyższego poziomu string. Fakt, że nie jest to stringmoduł biblioteki standardowej , nie pojawia się.

Aby uruchomić plik jako część pkgpakietu, możesz to zrobić

python -m pkg.script

W takim przypadku pkgkatalog nie zostanie dodany do ścieżki. Jednak bieżący katalog zostanie dodany do ścieżki.

Możesz również dodać szablon do, pkg/script.pyaby Python traktował go jako część pkgpakietu, nawet gdy jest uruchamiany jako plik:

if __name__ == '__main__' and __package__ is None:
    __package__ = 'pkg'

Jednak to nie wpłynie sys.path. Będziesz potrzebować dodatkowej obsługi, aby usunąć pkgkatalog ze ścieżki, a jeśli pkgkatalogu nadrzędnego nie ma na ścieżce, musisz go również umieścić na ścieżce.

Różnica między importem bezwzględnym i względnym pojawia się tylko wtedy, gdy importujesz moduł z pakietu, a ten moduł importuje inny podmoduł z tego pakietu. Zobacz różnicę:

$ mkdir pkg
$ touch pkg/__init__.py
$ touch pkg/string.py
$ echo 'import string;print(string.ascii_uppercase)' > pkg/main1.py
$ python2
Python 2.7.9 (default, Dec 13 2014, 18:02:08) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg.main1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "pkg/main1.py", line 1, in <module>
    import string;print(string.ascii_uppercase)
AttributeError: 'module' object has no attribute 'ascii_uppercase'
>>> 
$ echo 'from __future__ import absolute_import;import string;print(string.ascii_uppercase)' > pkg/main2.py
$ python2
Python 2.7.9 (default, Dec 13 2014, 18:02:08) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg.main2
ABCDEFGHIJKLMNOPQRSTUVWXYZ
>>> 

W szczególności:

$ python2 pkg/main2.py
Traceback (most recent call last):
  File "pkg/main2.py", line 1, in <module>
    from __future__ import absolute_import;import string;print(string.ascii_uppercase)
AttributeError: 'module' object has no attribute 'ascii_uppercase'
$ python2
Python 2.7.9 (default, Dec 13 2014, 18:02:08) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg.main2
ABCDEFGHIJKLMNOPQRSTUVWXYZ
>>> 
$ python2 -m pkg.main2
ABCDEFGHIJKLMNOPQRSTUVWXYZ

Zauważ, że python2 pkg/main2.pyma inne zachowanie niż uruchamianie, python2a następnie importowanie pkg.main2(co jest równoważne użyciu -mprzełącznika).

Jeśli kiedykolwiek zechcesz uruchomić podmoduł pakietu, zawsze używaj -mprzełącznika, który uniemożliwia interpreterowi połączenie sys.pathlisty i poprawnie obsługuje semantykę modułu podrzędnego.

Ponadto wolę używać jawnych importów względnych dla podmodułów pakietów, ponieważ zapewniają one większą semantykę i lepsze komunikaty o błędach w przypadku awarii.