[python] модули

import A

A.name

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

Не, циклический импорт не подходит.
Отдельный модуль тоже не очень.
Надо 2 модуля, т.к. надо сделать разделение проги на frontend и backend.

A стучиться в B с предложением поделиться ссылками на некоторые переменные.

Да, решение, но не очень удобное.

>Не, циклический импорт не подходит. >Отдельный модуль тоже не очень. >Надо 2 модуля, т.к. надо сделать разделение проги на frontend и backend.

Если у тебя backend вынужден обращаться к содержимому frontend-а, то что-то у тебя явно не так. Самое простое решение - отдельный модуль, чуть сложнее, но правильнее - пересмотреть в целом структуру аппликации ;)

> Надо 2 модуля, т.к. надо сделать разделение проги на frontend и backend.

а смысл, если они друг от друга будут зависеть? зависимость backend от frontend - это нонсенс!

а как? фронтендов может быть много.
бакенд - логика, фронтенд - кнопки и т.п.
бакенду иногда надо както изменить состояние кнопок.
буду рад, если поделитесь опытом!

Это не совсем фронтенд/бэкенд. Задача фронтенда - обеспечить для пользователя взаимодействие с бэкендом так, чтобы бэкенд ничего не знал про фронтенд, а разделение на логику и представление - это уже иное. Следует избегать двустороннего общения этих сущностей, если оно необходимо - следует ввести третью сущность, которая будет организовывать их совместную работу (google: Model-View-Controller).

> бакенду иногда надо както изменить состояние кнопок.

backend никаким образом не должен знать ничего о frontend. иначе это не backend =) например, frontend может быть консольным приложением, gtk-приложением, qt-приложением, web-мордой, etc.

сам же пишешь: "фронтендов может быть много."

и что, для каждого из них описывать поведение backend? какой тогда профит от такого разбиения? добавка тормозов и утолщение продукта? =)

> буду рад, если поделитесь опытом!

выше человек истину глаголит: через третий компонент. хотя, тоже коряво, ящитаю. за "кнопки" (UI будет точнее, верно? =) отвечает frontend, за всё остальное - backend. frontend зависит от backend, backend не зависит от frontend. и не надо никаких костылей.

если так хочется, можно в backend добавить вызовы типа GetState, GetNeededFeatureState и т.д.

> если так хочется, можно в backend добавить вызовы типа GetState, GetNeededFeatureState и т.д.

и на их результатах, конечно же, основывать поведение frontend ("кнопок")

во =)

>выше человек истину глаголит: через третий компонент. хотя, тоже коряво, ящитаю.

Кошерно - я предположил, что человеку нужно разделение логики и представление, а не фронтенд в суровом смысле этого слова, исходя чисто из того, что речь идёт о двух модулях в пределах двух аппликаций, а не о двух разных аппликациях, как это было бы логично в связке frontend-backend :)

>если так хочется, можно в backend добавить вызовы типа GetState, GetNeededFeatureState и т.д.

Большой костыль - что если фронтенд надо обновить после независимых изменений в логике? Дёргать GetState по таймеру? Добро пожаловать в ДОС. В случае разных апликаций на фронтенд и бэкенд фронтенд парсил бы каким-либо образом вывод бэкенда, в случае с модулями внутри одной апликации нужен как раз третий элемент (организующий систему эвентов, observer или что-то ещё). По сути, в первом случае такой элемент тоже есть, в его роли выступает система, внутри которой это крутится :)

> что если фронтенд надо обновить после независимых изменений в логике?

#include <signal.h> =)

> В случае разных апликаций на фронтенд и бэкенд фронтенд парсил бы каким-либо образом вывод бэкенда

тоже по таймеру? или постоянно? хммм... чем лучше?

а ещё можно использовать dbus, если сигналов не хватает =)

ну какбэ да, признаю, без третьего компонента (signals, dbus) - костыли ещё больше =)

>Как из B оратиться к глобальным переменным в A?

pipe, socket и тд

>#include <signal.h> =)

вот-вот, вот и третий компонент)

>> В случае разных апликаций на фронтенд и бэкенд фронтенд парсил бы каким-либо образом вывод бэкенда

>тоже по таймеру? или постоянно? хммм... чем лучше?

постоянно. лучше тем, что организуется мгновенная и асинхронная (т.е. не зависящая от прохода таймером по всем возможным изменениям) реакция.

>> В случае разных апликаций на фронтенд и бэкенд фронтенд парсил бы каким-либо образом вывод бэкенда

>тоже по таймеру? или постоянно? хммм... чем лучше?

для этого случая как раз именно сокеты рулят :)

>вот-вот, вот и третий компонент)

ну да, когда тот пост писал (про GetState)... "А слона-то я и не заметил" =)

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

про сокеты - согласен.

Вот я как раз про это...
Наверное я не правильно назвал это фронтэндом и бэкэндом.
Скорее есть основной модуль, в котором реализуется логика и есть несколько модулей-морд к нему, которые его импортируют.

Вот тут и получается костыльность, т.к. модулю с логикой надо:
- создавать экземпляры классов из морды
- делать им update_state

> - делать им update_state

я python, к сожалению, не знаю, но нельзя ли мордой передавать в основной класс указатель на функцию из себя, которую нужно вызывать при изменении state?

или у меня Си головного мозга? =) или я опять неправильно понял? =)

Ну, это да... неудобство с классами из морды.
хотя, как оказалось не сильное

#module A
import B
.....
B.SomeClass = SomeClass
.....

Манки-патчи для основной логики программы - плохой дизайн.

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

Ивенты? Почему бы не использовать обычные ивенты? Фронтэнд подписывается на ивент, бакэнд посылает ивент при изменении состояния, фронтэнд при получении ивента перерисовывает нужные ему кнопки как ему заблагорассудится. Чем плох подход?

Можно все модули оформлять в таком духе:

import Base
class MyClass(Base):
    ...
import Another1
import Abother2

Тогда всё будет работать, даже если два класса используют друг друга и получается циклический импорт.