DjangoBB LoFi version

Полная версия: Относительный импорт модулей

Начало » Python для новичков » Относительный импорт модулей

kostafey

Июль 8, 2011 18:32:26

Возможно, избитая тема, но все же.
Имеем следующую файловую структуру:

src\
    __init__.py
    main.py
src\test\
    __init__.py
    eggs.py
src\gui\
    __init__.py
    spam.py

Содержимое eggs.py:

x=2

Содержимое spam.py:

from test.eggs import x
print x

Содержимое main.py:

import gui.spam

Если просто выполнитть python main.py - все хорошо.

Если попытаться выполнить python spam.py - ошибка:
ImportError: No module named eggs

Если в spam.py попытаться написать:

from ..test.eggs import x

ошибка:
ValueError: Attempted relative import in non-package

Вопрос. Как протестировать модуль отдельно (в данном примере модуль spam.py),
если ему необходимо импортировать модули, лежащие в других пакетах?

Такого рода решение, как:

if __name__ == "__main__":
    import sys, os    
    sys.path.append(os.path.normpath(
        os.path.join(os.getcwd(), '..', 'test')))
    from eggs import x
else:
    from test.eggs import x

print x

работает, но выглядит не слишком красиво. Есть ли другие варианты решения?

Андрей Светлов

Июль 8, 2011 19:40:11

Откройте для себя setup.py

kostafey

Июль 9, 2011 03:14:02

Андрей Светлов
Откройте для себя setup.py

Регулярно пользуюсь им. Можно поконкретнее?

Июль 9, 2011 06:51:51

> Регулярно пользуюсь им.
Ага, ага, верю :-).

Не работайте с пакетами и модулями как с файлами, работайте с ними как с пакетами и модулями.

>> python -c“import src.main”
>> python -c“import src.gui.spam”

Посмотрите virtualenv, научитесь из своего кода делать дистрибутивы (этот самый setup.py, “Distributing Python Modules” в справке, setuptools, distibute и пр.), всё сведётся к:

Один раз:
$ virtualenv –distribute myenv
$ . myenv/bin/activate
$ cd myenv/myproject && python setup.py develop

И дальше только:
$ myenv/myproject/bin/mycoolscript –mycoolarg1 –mycoolarg2
$ myenv/myproject/bin/mycoolscript –mycoolarg3
$ myenv/myproject/bin/mycoolscript –mycoolarg4

Или:
$ . myenv/myproject/bin/activate
$ mycoolscript –mycoolarg1 –mycoolarg2
$ mycoolscript –mycoolarg3
$ mycoolscript –mycoolarg4

p.s. “src” это плохое имя для пакета (в контексте “import src.gui.spam” ;-).

p.p.s. К тому же, что это за “выполнить python spam.py”, откуда выполнить? Мы знаем, как Python ищет и находит пакеты/модули? Мы ведь понимаем что то, какая сейчас (при передаче скрипта интерпретатору) директория является текущей играет таки роль при поиске пакетов/модулей этим интерпретатором?

..bw

kostafey

Июль 11, 2011 14:36:00

bw
> Регулярно пользуюсь им.
Ага, ага, верю :-).

Ладно, я использую setup.py для целей py2exe.
Подскажите пожалуйста что там должно быть в контексте данной задачи?

Про virtualenv не совсем понял. Получается, что нужно перед тестированием модуля
всякий раз устанавливать разрабатываемые скрипты в bin (в случае винды в Scripts).
У вас это по всей видимости выполняется по команде.
python setup.py develop

Test\src\foo.py

I:\WorkDir\workspace\Test>virtualenv.py --python=C:\Python27\python.exe --distribute testenv
I:\WorkDir\workspace\Test>testenv\Scripts\activate.bat
? setup
I:\WorkDir\workspace\Test>cd src
? I:\WorkDir\workspace\Test\src>foo.py

Можно поподробнее про setup.py и develop?

И да, есть ли боле простые пути?

Июль 11, 2011 18:46:12

> всякий раз
Один раз.
Ну и любой запуск из среды потребует либо указание пути к python в этой среде, либо использование activate. Хотя под виндой такой хернёй не страдал, давно ей не пользуюсь.

Поищи в сети. И скажи твой уровень (опыт) работы с языком и вообще в программировании. Это я к тому, что просто посыл тебя ключевыми словами не работает, тебя нужно другими словами посылать :-).
Покажи мне свой псевдопроект (максимально упрощённый, но так же не работающий) (мылом или ещё где выложи в архив). Я оформлю как следует, может так будет тебе проще понять.

..bw

kostafey

Июль 12, 2011 14:11:03

bw
Один раз.
Ну и любой запуск из среды потребует либо указание пути к python в этой среде, либо использование activate. Хотя под виндой такой хернёй не страдал, давно ей не пользуюсь.

А, ну это здорово. Мне винда/не винда не суть. Есть машины и с виндой и с линуксом, но
в конечном итоге приложения разрабатываются для виндовых пользователей.

bw
Поищи в сети. И скажи твой уровень (опыт) работы с языком и вообще в программировании. Это я к тому, что просто посыл тебя ключевыми словами не работает, тебя нужно другими словами посылать :-).

После того, как меня последний раз так послали, я пробежал пару марафонов ;)

Я просто думал, что setup.py используется только для распространения
готовых приложений и не знал, что это можно в процессе разработки
использовать.

Уроовень - э-э-э… затрудняюсь ответить мне просто не с чем (не с кем) сравнивать.
Я имел опыт работы в других языках (последнее время java для web), но в python
пришел только недавно.

bw
Покажи мне свой псевдопроект (максимально упрощённый, но так же не работающий) (мылом или ещё где выложи в архив). Я оформлю как следует, может так будет тебе проще понять.

Насчет “так же не работающий”… ну я не знаю как написать __не__
работающее приложение :)

Суть в том, что PyDev при запуске текущего модуля работает совершенно
нормально. Возможно, там как раз механизм вызова модуля заключается в
том, что он запускает python-процесс в корневой директории проекта и
импортирует (перегружает) данный модуль. Так что там все работает и
так хорошо. Проблемы начались, когда я попробовал настроить работу в
ropemacs. Так вот я и стал пробовать просто выполнять файлы модулей
как скрипты. От туда наткнулся на проблему необходимости импорта
модулей, которые лежат в другом пакете. Видимо, я не правильно понял
содержимое справки:
http://www.python.org/dev/peps/pep-0328/#guido-s-decision
http://docs.python.org/tutorial/modules.html#intra-package-references

Типовые приложения с которыми сейчас работаю - приложения для конечных
пользователей с гуи, бд, шблонами документов и т.д. setup.py
используется для получения exe-шника.

Я был бы очень признателен за помощь в настройке virtualenv для того,
чтобы можно было тестировать тот же foo.eggs сам по себе, не завися
при этом от среды разработки в проекте такого плана (setup.py в
комплекте):

http://dl.dropbox.com/u/820526/test.zip