так гил же на io освобождается )))

Фейк, не?

В любом случае это успех нашего рынка. :)

Не знаю, фейк ли данное конкретное фото, но недавно прочитала с интересом статью Вастрика про разные способы определения фейковых снимков. Товарищ пишет в очень свободной манере, своеобразный слог. Но обзоры у него (кроме этого, например, про умный дом или вычислительную фотографию) очень неплохи.

https://vas3k.ru/blog/390/

Да-да, прекрасный товарищ. У него ещё самый адекватный разбор MacBook Pro, что я видел

а не встречал ли кто-нибудь хорошей статьи с описанием подходов по организации импортов (и кода, конечно)?
а то я что-то с циклическими импортами себе все ноги отстрелил :(

Из __init__.py нельзя импортировать ничего в текущем пакете. Только из верхнего.

Тоесть не определять db в app и потом тащить его в app.views. А только в отдельном модуле db.

Циклические импорты - это чаще всего импорты ресурсов. Лучше их пробрасывать не в import time. Через теже blueprints, drf context или мои dependencies.

Тут скорее надо статью не про импорты, а про то что твои "сущности" в коде должны иметь исключительно однонаправленные зависимости. Например:
- есть "юзеры" - они сами по себе и знают только про себя.
- есть "картинки" - они знают про про "юзера" который их залил.
- есть "коменты", они знают про "юзера" который их создал, и про "картинки", которые в них добавили.

И только вот так, сверху вниз растущее дерево. В реализации юзеров не должно быть ни грамма кода который знает про коменты или картинки. В реализации картинок не должно быть ничего про коменты.
Если же нужные какие-то "знания" про "дочерние" объеткы, то надо использовать любую удобную для тебя реализацию IoC, но не делать прямые импорты.

Если без импортов ну ни как не получается - значит ты не правильно построил "дерево зависимостей", не так распределил ответсвености. Вероятно надо выделить ещё доп. сущность, которая будет объединять две имеющиеся без создания циклических импортов

Смотреть с указанного времени

спасибо ребят, буду внимательно смотреть, что мне со всем этим делать, конечно надо реорганизовать.
отдельная фигня в питоне, он позволяет импортировать внутри функции, как же это развращает, индусский код получается

__init__.py у меня всегда и везде пустой, давно решил что так делать правильно

Можно ещя в теле класса импортировать, чтобы в наследнике потом иметь возможность скоуп переопределить.

поясни пожалуйста, импортировать в __init__ класса? чтоб в наследнике переопределить инит и заимпортить что-то другое? верно я понял?
звучит как-то не очень, так точно можно делать?

это хорошо в теории. А на практике у тебя будет
у каждого юзера есть и картинки и комментарии. Комментарии и его и ему.
в комментриях есть ссылки на картинки и ссылки на юзеров (@-нотация)
у картинок есть собственные комментарии.

Хз как сделать так чтобы каждый объект не знал другие..

Вполне понятно как, например через IoC. Тут ведь речь не про то что юзеры (как абстракция) в принципе не знают про что-то (хотя стремится к этому - неплохо). А про то что именно на уровне объектов кода "юзеры" не знают про конкретную реализацию коментов.
Они могут знать про "интерфейс" коментов, или просто про "интерфейс" любого дочернего ресурса. И через этот интерфейс могут использовать эти дочерние ресурсы не выполняя в коде явного импорта кода с реализацией этих ресурсов.

Кроме того всегда можно написать "третью" сущность, которая объединяет другие две. Например написать компонент который реализует юзера знающего про коменты, и он будет делать прямые импорты из юзеров и из коментов 😊