>в таком случае необходимо будет сделать контролер, которые совмещает действия других таких же классов.
Зачем?
>не хватает винтика, который бы управлял и связывал все части этого кода.
Вы хотите написать «САМЫЙ ГЛАВНЫЙ КЛАСС»? :-) Он необязательно нужен.
Вообще, такоой подход неверен. Эстетисческая составляющая и желания разработчиков не существенны. Какую проблему Вы хотите решить этим классом? Если есть конкретная проблема, то решайте, если нет — забейте. «Нам не хватает винтика…» — это не проблема.
Судя по всему python вам вообще не нужен. Для игрушек достаточно JavaScript. Ну или наоборот, достаточно Python + pygame.
Если же Вы всё-таки хотите делать что-то, для чего нужен сервер, то всё зависит от того, чему хотите научить.
Если «как оно всё работает внутри», то фреймворк будет вреден, так как скрывает реализацию.
Если «как создавать законченный продукт (сайт)» то фреймворк строго обязателен — он намного упростит дело.
Большинству учеников, скорее всего, ближе будет второй вариант, т.к. он даст что-то законченное и работающее. Особо продвинутым можно дать отдельное задание «сделайте это без фреймворка».
@Lafafm, если я правильно всё понял, то смело сохраняйте в базе. Хотя, если этим пользуетесь только Вы, проще сделать конфиг и править его руками по необходимости (как понимаю, где-то раз в месяц). Тогда не нужно будет делать кучу лишних вещей.
Потому что совершенно не ясен контекст. Если бы не было тега PHP я бы решил, что вы пишите GUI на каком-нибудь С++ (собственно поэтому я про MVC и вспомнил).
Опции (даже в вебе) разные бывают. И хранить их можно по-разному, в зависимости от того, где они нужны (на что влияют). Универсальный подход — в базе. Но можно, например, и в cookies, если опция локальна для сессии. Можно в кэше, если её наличие не принципиально. А можно вообще в хранилище браузера и передавать при необходимости дополнительным параметром url.
Чётко опишите ситуацию: что надо получить, что для этого делается и в чём заключается проблема
Я перешёл на Python с C++. На обоих языках делал большие проекты. Сложность сопровождения с видом типизации слабо коррелирует. При грамотной архитектуре и толковых разработчиках разницы нет.
Если команда слабенькая (студенты) или плохо налажена коммуникация, то могут быть некоторые проблемы. Статическая типизация в основном позволяет устранить элементарные ошибки, свойственные новичкам, в то время как основные проблемы при разработке и поддержке идут как раз не от них.
С точки же зрения разработки, на ЯП с динамической типизацией она реально быстрее.
В таком случае проверка наличия метода — это нормальный подход. Duck Typing и всё такое.
Хотя, я бы предложил явную регистрацию «интерфейсных» методов. Не обязательно накладывать на разработчиков плагинов лишние ограничения (в данном случае по именованию). Мало ли что потом изменится.
P.S. Функция getattr имеет возможность возвращать дефолтное значение, если не находит аттрибут. Поэтому можно и так написать: getattr(plugin, 'on', lambda *argv, **kwargs: None)() И никаких проблем с интерфейсами :-)
Это как в анекдоте про «неуловимого Джо», пока некому переходить с Го на Питон, т.к. и самих гошников мало, а гошников не знающих Питон или аналоги, видимо, ещё меньше.
По моим наблюдениям, они всё-таки на разных уровнях там используются (хотя местами и пересекаются, о веб-фреймворках на го слышал).
Сейчас, имхо, сложно чётко определить куда Го приткнётся, он ещё слишком молод, люди экспериментируют много. Но мне кажется, он ближе и удобнее для системного программирования, что-то вроде наследника С.
>не измерял профайлером
Лучше всё-таки измерить. Или хотя бы посмотреть количество и тип запросов к базе. Я с трудом представляю, что может рендерится полсекунды.
>только for с товарами
сходу возможные проблемы:
- итарация по запросу *.objects.all() может вызывать несколько запросов (т.к. Джанго будет запрашивать данные по мере необходимости);
- для каждого товара могут вызываться дополнительные запросы при обращении к связанным с ним моделям (см. select_related)
Зачем?
>не хватает винтика, который бы управлял и связывал все части этого кода.
Вы хотите написать «САМЫЙ ГЛАВНЫЙ КЛАСС»? :-) Он необязательно нужен.
Вообще, такоой подход неверен. Эстетисческая составляющая и желания разработчиков не существенны. Какую проблему Вы хотите решить этим классом? Если есть конкретная проблема, то решайте, если нет — забейте. «Нам не хватает винтика…» — это не проблема.