• Как организовать структуру игры?

    >в таком случае необходимо будет сделать контролер, которые совмещает действия других таких же классов.
    Зачем?

    >не хватает винтика, который бы управлял и связывал все части этого кода.
    Вы хотите написать «САМЫЙ ГЛАВНЫЙ КЛАСС»? :-) Он необязательно нужен.

    Вообще, такоой подход неверен. Эстетисческая составляющая и желания разработчиков не существенны. Какую проблему Вы хотите решить этим классом? Если есть конкретная проблема, то решайте, если нет — забейте. «Нам не хватает винтика…» — это не проблема.
  • Обязательно ли изучать python фреймворк для разработки сайта или игры?

    Судя по всему python вам вообще не нужен. Для игрушек достаточно JavaScript. Ну или наоборот, достаточно Python + pygame.

    Если же Вы всё-таки хотите делать что-то, для чего нужен сервер, то всё зависит от того, чему хотите научить.

    Если «как оно всё работает внутри», то фреймворк будет вреден, так как скрывает реализацию.

    Если «как создавать законченный продукт (сайт)» то фреймворк строго обязателен — он намного упростит дело.

    Большинству учеников, скорее всего, ближе будет второй вариант, т.к. он даст что-то законченное и работающее. Особо продвинутым можно дать отдельное задание «сделайте это без фреймворка».

    P.S. Возможно Вам будет интересен этот текст: tiendil.org/pages/webdev
  • Как реализовать изменение программы средствами интерфейса ?

    @Lafafm, если я правильно всё понял, то смело сохраняйте в базе. Хотя, если этим пользуетесь только Вы, проще сделать конфиг и править его руками по необходимости (как понимаю, где-то раз в месяц). Тогда не нужно будет делать кучу лишних вещей.
  • Как реализовать изменение программы средствами интерфейса ?

    Потому что совершенно не ясен контекст. Если бы не было тега PHP я бы решил, что вы пишите GUI на каком-нибудь С++ (собственно поэтому я про MVC и вспомнил).

    Опции (даже в вебе) разные бывают. И хранить их можно по-разному, в зависимости от того, где они нужны (на что влияют). Универсальный подход — в базе. Но можно, например, и в cookies, если опция локальна для сессии. Можно в кэше, если её наличие не принципиально. А можно вообще в хранилище браузера и передавать при необходимости дополнительным параметром url.

    Чётко опишите ситуацию: что надо получить, что для этого делается и в чём заключается проблема
  • Какой более подходящий стек для веб приложения реального времени (граф. редактор)?

    Я перешёл на Python с C++. На обоих языках делал большие проекты. Сложность сопровождения с видом типизации слабо коррелирует. При грамотной архитектуре и толковых разработчиках разницы нет.

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

    С точки же зрения разработки, на ЯП с динамической типизацией она реально быстрее.
  • Какой более подходящий стек для веб приложения реального времени (граф. редактор)?

    Приведённые минусы мне совершенно непонятны.

    Каких конкретно проблем с масштабируемостью Вы боитесь?

    Куча топовых сайтов работают на Python и не испытвают никаких проблем с производительностью.
  • Python-way и интерфейсы

    В таком случае проверка наличия метода — это нормальный подход. Duck Typing и всё такое.

    Хотя, я бы предложил явную регистрацию «интерфейсных» методов. Не обязательно накладывать на разработчиков плагинов лишние ограничения (в данном случае по именованию). Мало ли что потом изменится.

    P.S. Функция getattr имеет возможность возвращать дефолтное значение, если не находит аттрибут. Поэтому можно и так написать: getattr(plugin, 'on', lambda *argv, **kwargs: None)() И никаких проблем с интерфейсами :-)
  • Python-way и интерфейсы

    В питоне правильно не проверять протоколы, а ловить исключения :-)

    В большинстве случаев, нереализация интерфейса — это явная ошибка и надо падать.

    Если сранивать ABC и Михины, то ABC идеалогически более верно использовать (раз в официальной документации на них указывают).
  • Стоит ли переходить с Python на Go?

    Это как в анекдоте про «неуловимого Джо», пока некому переходить с Го на Питон, т.к. и самих гошников мало, а гошников не знающих Питон или аналоги, видимо, ещё меньше.
  • Стоит ли переходить с Python на Go?

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

    Сейчас, имхо, сложно чётко определить куда Го приткнётся, он ещё слишком молод, люди экспериментируют много. Но мне кажется, он ближе и удобнее для системного программирования, что-то вроде наследника С.
  • Как лучше организовать кэширование в Django?

    >не измерял профайлером
    Лучше всё-таки измерить. Или хотя бы посмотреть количество и тип запросов к базе. Я с трудом представляю, что может рендерится полсекунды.

    >только for с товарами
    сходу возможные проблемы:
    - итарация по запросу *.objects.all() может вызывать несколько запросов (т.к. Джанго будет запрашивать данные по мере необходимости);
    - для каждого товара могут вызываться дополнительные запросы при обращении к связанным с ним моделям (см. select_related)