Алексей Елецкий

Смотря что Вы хотите с этими словами делать.

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

Если надо редактировать, ложите в базу.

Делайте красивый прототип, ищите БОЛЬШИЕ деньги, удаляйте нафиг прототип, долго и упорно делайте удобный для врачей софт, ????, получайте профит.

Только не втюхивайте, пожалуйста, полугодичную поделку как работающий инструмент реальным мед. учреждениям. С медициной и так всё плохо, не надо ещё больше людей мучать.

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

Называйте с учётом имени приложения, для которого определяются модели, так как оно несёт дополнительную семантику. Поэтому, если в приложении ожидаются только теги одного типа, то указывать к чему они относятся не надо. Если ожидаются теги для разных сущностей (что, для тегов, странно), то уже надо указать.

Скорее всего у вас будет что-то вроде

from forum import models as forum_models

do_smth_wiht(forum_models.Post)
do_smth_wiht(forum_models.Tag)

Если

Напишите пару мелких игрушек, хотя бы тетрис или змейку. Но полноценные: с интерфейсом, конфигурацией, сохранениями, звуком и так далее.

В процессе потыкаетесь в кучу разных областей.

Как заметил Ришат Кадыров, производительность людей важнее производительности кода. Поэтому явных преимуществ именно между языками нет. На выбор влияет наличие инструментов: библиотек, фреймворков.

Это влияние хорошо демонстрирует Ruby, который стал популярен только благодаря появлению Ruby On Rails и с тех пор, в общем, ничем другим не отметился.

А появление фреймворков, во многом, случайное явление. Кто-то талантливый реализовал какую-то новую идею на том, что ему было удобно — язык реализации получил небольшое преимущество. Сочетание таких случайностей и делает «специализацию» языка.

Плюс, в разных областях есть немного разные требования к семантике ЯП, некоторые концепты проще реализовать на одном языке, чем на другом.

>Не подскажете, как лучше всего реализовать размещение web-приложения на этих серваках?
Не надо никак организовывать. Опишите проблему, которую хотите этим решить, тогда можно будет что-то сказать. Если проблемы нет, используйте один сервер.

Чем готовые шаблонизаторы не устраивают? Вот, например, jinja.pocoo.org/docs/dev

Код будет выглядеть примерно так: {{rand(3, 10)}} {{randline("bla-bla")}}

Вместо {{ и }} можно настроить использование любых других сиволов

Все «мейнстримные» ЯП востребованы.
Для всех не хватает специалистов.
Профессионалы получают хорогую зп независмо от ЯП. ЗП скорее зависит от проекта и компании.
Поэтому устроиться не проблема, при наличии знаний.
Ищите вакансии в крупных компаниях, мелкие и средние не рискуют брать новичков на обучение, т.к. те часто меняют работу, получив необходимый опыт.

Программирование может пригодиться абсолютно в любой области человеческой деятельности. Надо бы уточнить вопрос.

Вы составили неправильное представление о том, что такое паттерны.

Паттерн — это не конкретная реализация чего-то, а подход к организации. То, что описано в книгах — это некое обобщение опыта разработчиков. На каждом ЯП паттерны могут быть реализованы по разному. Более того, т.к. паттерн, сам по себе, — обобщение опыта, то даже на одном ЯП он может быть реализован по-разному, в зависимости от контекста, в котором он используется и конкретного программиста.

Соответственно, любой паттерн можно использовать на любом тьюринг полном ЯП.

Кстати, События — это тоже паттерн, просто в некоторых ЯП он реализован на уровне языка, в других реализуется вручную. Там где их нет, их можно реализовать самому или использовать одну из готовых библиотек.

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

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

Если к геймдеву никак не относитесь — осваивайте нужную профессию или ищите деньги.

При DEBUG=True Django сохраняет все запросы, проведённые к базе. Возможно, это это как-то влияет.

Подробнее см. тут: https://docs.djangoproject.com/en/1.7/faq/models/#...

Определить декоратор нельзя, если это не предусмотрено самим декоратором.

Конкретно данную задачу я бы решал всё-таки через передачу настроек в функцию.

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

Другой вариант — сделать декоратор для декораторов, который будет возвращать новый декоратор, который будет вешать нужный маркер…

Хорошо распространена. В геймдеве такой подход популярен.

Но вопрос некорректен. Без разницы на сколько распространена практика — условия должны оговариваться с конкретными людьми. Если они всех устраивают — хорошо, не устраивают — распространённость практики ничем не поможет.

А Вам хоть один из перечисленных плюсов критичен? То есть вы действительно в него упираетесь?

Если да, используйте, если нет — не надо.

KISS