Форум сайта python.su
Здравствуйте.
Начал изучать.
Не могу победить import, вернее ошибку импорта.
Проект выглядит так:
/project_root
—-settings/
——–config.py
—-db/
——–creator.py
В папке settings лежит файл с настройками. В настройка прописано название БД.
В папке db лежит файл creator.py, который создаёт sqlite базу.
Пытаюсь импортировать config.py в creator.py так:
from settings import config
ModuleNotFoundError: No module named ‘settings’
cp = (os.path.abspath(os.curdir)) with os.scandir(cp) as files: subdir = [file.name for file in files if file.is_dir()] print(subdir)
Офлайн
rmnТут надо понять что в строке импорта указываются вовсе не пути. Это перечень вложенных пакетов который завершается опционально модулем. Есть вполне определенные правила поиска модулей и пакетов:
Подскажите пжл, что делаю не так.
Уже и относительные пути все перепробовал и абсолютные.
Отредактировано doza_and (Янв. 18, 2022 07:55:35)
Офлайн
doza_andСпасибо большое.
Вы, очевидно, не выполняете эти правила.
curDir = os.getcwd()
sys.path.append(curDir)
Офлайн
rmnЕсли такое нужно делать, то проект просто как-то неправильно организован. Это костыль, а костыль - это не нога.
Затем, добавил этот путь в систем паз:Всё работает.sys.path.append(curDir)
Много где подобное советуют
Офлайн
py.user.nextСоглашусь пожалуй.
Если такое нужно делать, то проект просто как-то неправильно организован. Это костыль, а костыль - это не нога.
Офлайн
rmnМиллион леммингов не может ошибаться. Ну да. Также можно найти миллион советов в стиле “используй os.getcwd()”. Ты вообще про эту функцию вспоминать не должен никогда. Она вообще очень редко когда тебе понадобится во всём твоём программировании в ближайшие десятки лет и то при работе с каким-то там текущим каталогом в какой-нибудь редкой функции.
Очень распространенная проблема, судя по поисковой выдаче.
rmnНу, кроме питона, программирование ещё есть. И вот это - инфа про модули - это теория программирования. То есть ты и в питоне новичок, и в программировании ты тоже новичок.
Я ж учусь только.
Отредактировано py.user.next (Янв. 19, 2022 02:56:40)
Офлайн
py.user.nextЕсли функционал есть, значит он зачем-то нужен, да?
Ни переменные среды, ни редактирование путей, - ничего такого там не надо делать.
py.user.nextАбсолютно верно. Но только, если это именно модуль, а не пакет. Вобще сложно пока понять на кой чёрт создатели сделали такую универсальность. Каталог может быть модулем, а может пакетом. Лучшее - враг хорошего.
потому что один модуль никогда не должен знать что-либо про внутренности другого модуля
py.user.nextМожно пример?
Модули если и знают друг про друга вообще, то они общаются максимум через внешние границы, хорошо формализованные.
py.user.nextЕщё раз. В ПАКЕТЕ settings лежит файл конфигурации. Класс с некими свойствами, в том числе и с названием базы. Которые нужно считывать отовсюду, где нужно.
Каким макаром у тебя модуль db знает имена файлов в модуле settings?
py.user.nextЗа это спасибо. Надо изучить как добавлять. Я то решил, что достаточно пустого файла в любом каталоге, который хочу использовать как пакет.
В пакетном __init__.py файле должны быть все импорты, которые нужны там где-то внутри этого пакета.
py.user.nextТак и намеревался реализовать. Где в моём подходе я неправ? И как бы сделал ты?
И никто из пакета не должен вылазить наружу, чтобы что-то там раздобыть. Все обращаются к самому модулю, в котором они находятся, и просят его “дай мне такой-то модуль, чтобы я у него попросил то, что он там может делать”.
py.user.nextСпасибо за развёрнутый ответ. Честно.
миллион советов
Офлайн
rmnНе всегда это так. Иногда функционал есть для того, чтобы его проверить. Если он покажет свою нужность и успешность, полезность такую, то его оставят и будут развивать дальше. А если он окажется неиспользуемым, рудиментарным (как хвостик у человека, который ещё есть иногда), то его удалят (пометят как deprecated сначала, а потом и вовсе вырежут из будущих версий, как отвалившуюся сухую ветку у растения, которая когда-то там была зелёной и полной сил).
Если функционал есть, значит он зачем-то нужен, да?
rmnНет такого понятия “пакет”. Это внутреннее понятие из языка программирования. Сначала оно в Java было, потом в Python переехало. Конечно, оно не в Java началось, но так как Java - объектно-ориентированный язык, а Python хотели сделать объектно-ориентированным, то и понятие пакета в Python'е тоже воспроизвели. Хотя в разных языках эти пакетные системы, где они есть вообще, по-разному устроены. То есть, я думаю, они хотели, как в Java, но чтобы не как в Java, а чтобы по-своему как-то сделать их. Так-то пакетные системы известны ещё до ООП, но они не были тогда хорошо и чётко формализованы.
Абсолютно верно. Но только, если это именно модуль, а не пакет.
rmnКаталог не может быть модулем. Модулем может быть только файл. А каталог может быть каталогом или пакетом. Пакетом он становится, если в нём обнаруживается файл __init__.py .
на кой чёрт создатели сделали такую универсальность. Каталог может быть модулем, а может пакетом.
rmnНу, как колесо к оси крепится? На оси есть такие болтики и на колесе есть такие дырочки и к ним гаечки. Вот ось - это модуль, колесо - это модуль. Вот эти болтики на оси - это внешний интерфейс оси. А дырочки на колесе - это внешний интерфейс колеса. Через свои внешние интерфейсы эти два модуля прикрепляются друг к другу. То есть ось не знает про шину в колесе. А колесо не знает, какие там подшипники в оси. Шина - это внутренняя часть модуля, который представлен колесом. А подшипники - это внутренняя часть модуля, который представлен осью. Они внутренние не потому, что их не видно, а они внутрение потому, что их “не видно”. То есть их можно убрать и это ничего не изменит. Вот как колесо крепилось к оси, так оно и будет дальше крепиться к оси как без подшипников в оси, так и без шины на колесе. Как оно было накачанным, так оно и останется накаченным без подшипников в оси. Как ось вращалась, так она и будет вращаться, если с колеса снять шину вообще.py.user.nextМожно пример?
Модули если и знают друг про друга вообще, то они общаются максимум через внешние границы, хорошо формализованные.
rmnА это вот говорит онfrom settings import config
rmnModuleNotFoundError: No module named 'settings'
rmnНе, это не ConfigParser, это надо изучить, как это делают другие. Думаю, там settings как раз для этого, просто у тебя не простроена хуйня вся. Скорее всего, вот эта среда что-то делает, а ты этого не делаешь. Она простраивает, а ты нет. Поэтому в ней видно, а у тебя - хуй.
Пока решил использовать configParser, отказался от своей реализации конфигурации.
rmnМожет быть досточно, а может быть недостаточно.
Я то решил, что достаточно пустого файла в любом каталоге, который хочу использовать как пакет.
rmnСначала почитал бы документацию. Обычно это самая быстрая хуйня. Ты как бы не первый человек, который делает такое приложение, поэтому кто-то уже его делал и кто-то из них его уже сделал и написал документацию, как его делать, чтобы его сделать. То есть документация чаще всего есть, чем её нет. Потом бы запустил help(имя_пакета), потому что там уже физически видно, что доступно. И потом, может быть, я стал бы лазить и выяснять, как они в среде своей это сделали. Но, скорее всего, я бы это бросил и вернулся к документации, потому что что-то пропустил, а это выяснение про эту среду всё равно никак не поможет, потому что не факт, что это лучший способ. Это костылём среды может быть. Да! Бывает такое! Что в средах и других программах бывают костыли, которые перенимешь такой радостный, а потом из-за них у тебя что-нибудь сломается в итоге и в самый неожиданный момент, когда у тебя времени на то, чтобы это исправлять, вообще не будет.
Где в моём подходе я неправ? И как бы сделал ты?
Отредактировано py.user.next (Янв. 20, 2022 02:13:20)
Офлайн