после ошибки пакета верхнего уровня в относительном импорте

Кажется, здесь уже есть несколько вопросов об относительном импорте в Python 3, но, пройдя многие из них, я так и не нашел ответа на свой вопрос. так вот в чем вопрос.

У меня есть пакет, показанный ниже

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

и у меня есть одна строка в test.py:

from ..A import foo

Теперь я в папке package, и я бегу

python -m test_A.test

Я получил сообщение

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

но если я нахожусь в родительской папке package, например, я запускаю:

cd ..
python -m package.test_A.test

все хорошо.

Теперь мой вопрос: когда я нахожусь в папке packageи запускаю модуль внутри подпакета test_A, так как test_A.test, исходя из моего понимания, ..Aподнимается только на один уровень, который все еще находится внутри packageпапки, почему он выдает сообщение, говорящее beyond top-level package. В чем именно причина этого сообщения об ошибке?

РЕДАКТИРОВАТЬ: Есть лучшие / более последовательные ответы на этот вопрос в других вопросах:

• Импорт пакета родного брата
• Относительный импорт в миллиардный раз

Почему это не работает? Это потому, что python не записывает, откуда был загружен пакет. Таким образом, когда вы это делаете python -m test_A.test, он в основном просто отбрасывает знания, которые test_A.testна самом деле хранятся package(то packageесть не считается пакетом). Попытка from ..A import fooпытается получить доступ к информации, которой у него больше нет (например, каталоги соседних узлов загруженного местоположения). Концептуально это похоже на разрешение from ..os import pathв файле в math. Это было бы плохо, потому что вы хотите, чтобы пакеты были разными. Если им нужно использовать что-то из другого пакета, тогда они должны обращаться к ним глобально с помощью from os import pathи позволить Python выяснить, где это с $PATHи $PYTHONPATH.

Когда вы используете python -m package.test_A.test, тогда использование from ..A import fooрешает просто отлично, потому что он отслеживает, что находится, packageи вы просто получаете доступ к дочернему каталогу загруженного местоположения.

Почему Python не считает текущий рабочий каталог пакетом? НЕТ КЛИПА , но черт возьми, это было бы полезно.

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

Попробуй это. Работал на меня.

Предположение:
если вы находитесь в packageкаталоге, Aи test_Aотдельные пакеты.

Вывод:
..Aимпорт разрешен только внутри пакета.

Дополнительные примечания:
Сделать относительный импорт доступным только в пакетах полезно, если вы хотите, чтобы пакеты могли быть размещены на любом пути, расположенном на sys.path.

РЕДАКТИРОВАТЬ:

Я единственный, кто думает, что это безумие !? Почему в мире текущий рабочий каталог не считается пакетом? - Мультихантер

Текущий рабочий каталог обычно находится в sys.path. Итак, все файлы там импортируются. Это поведение начиная с Python 2, когда пакеты еще не существовали. Создание действующего каталога как пакета позволило бы импортировать модули как «import .A» и как «import A», которые затем будут двумя разными модулями. Может быть, это несоответствие, чтобы рассмотреть.

Ни одно из этих решений не работало для меня в 3.6 с такой структурой папок, как:

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

Моей целью было импортировать из module1 в module2. Что, наконец, сработало для меня, было, как ни странно,

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

Обратите внимание на одну точку, в отличие от упомянутых выше двухточечных решений.

Изменить: следующее помогло прояснить это для меня:

import os
print (os.getcwd())

В моем случае рабочий каталог был (неожиданно) корневым каталогом проекта.

from package.A import foo

Я думаю, что это яснее, чем

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

Как подсказывает самый популярный ответ, в основном это потому, что ваш PYTHONPATHили sys.pathвключает, .но не ваш путь к вашей посылке. И относительный импорт относится к вашему текущему рабочему каталогу, а не к файлу, в который происходит импорт; как ни странно.

Вы можете исправить это, сначала изменив относительный импорт на абсолютный, а затем либо начав с:

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

ИЛИ форсировать путь Python при вызове таким образом, потому что:

С python -m test_A.testвы выполняете test_A/test.pyс __name__ == '__main__'и__file__ == '/absolute/path/to/test_A/test.py'

Это означает, что test.pyвы можете использовать свой абсолютный importполу-защищенный в главном случае, а также выполнить одноразовые манипуляции с путями Python:

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

Изменить: 2020-05-08: Кажется, что сайт, который я цитировал, больше не контролируется человеком, который написал совет, поэтому я удаляю ссылку на сайт. Спасибо, что сообщили мне знать baxx.

Если кто-то все еще немного борется после того, как хорошие ответы уже предоставлены, я нашел совет на веб-сайте, который больше не доступен.

Основная цитата с сайта, который я упомянул:

«То же самое можно указать программно следующим образом:

импорт системы

sys.path.append ( '..')

Конечно, код выше должен быть написан перед другим оператором импорта .

Совершенно очевидно, что так и должно быть, думать об этом после факта. Я пытался использовать sys.path.append ('..') в своих тестах, но столкнулся с проблемой, опубликованной OP. Добавив определение import и sys.path до других моих импортов, я смог решить эту проблему.

Если у вас есть __init__.pyв верхней папке, вы можете инициализировать импорт, как import file/path as aliasв этом файле инициализации. Затем вы можете использовать его в нижних скриптах как:

import alias

По моему скромному мнению, я так понимаю этот вопрос:

[Случай 1] Когда вы начинаете абсолютный импорт, как

python -m test_A.test

или

import test_A.test

или

from test_A import test

вы на самом деле установка импорт-якорь , чтобы быть test_A, другими словами, пакет верхнего уровня test_A. Итак, когда у нас есть test.py do from ..A import xxx, вы убегаете от якоря, а Python не позволяет этого.

[Случай 2] Когда вы делаете

python -m package.test_A.test

или

from package.test_A import test

Ваш якорь становится package, таким package/test_A/test.pyобразом from ..A import xxx, не удаляется якорь (все еще внутри packageпапки), и Python с радостью принимает это.

Коротко:

• Абсолютный импорт изменяет текущую привязку (= переопределяет, что является пакетом верхнего уровня);
• Относительный импорт не меняет привязку, но ограничивает ее.

Кроме того, мы можем использовать полное имя модуля (FQMN) для проверки этой проблемы.

Проверьте FQMN в каждом случае:

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

Таким образом, для CASE2, результатом from .. import xxxбудет новый модуль с FQMN = package.xxx, что является приемлемым.

В то время как для CASE1, ..изнутри from .. import xxxвыпрыгнет из начального узла (якоря) test_A, и это НЕ разрешено Python.

Не уверен в python 2.x, но в python 3.6, если вы пытаетесь запустить весь пакет, вы просто должны использовать -t

-t, --top-level-directory directory Каталог верхнего уровня проекта (по умолчанию это начальный каталог)

Итак, на структуре, как

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

Например, можно использовать:

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

И все еще ввозить my_module.my_classбез крупных драм.