Anatoly Scherbakov

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

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

Необходимо:
1) создавать поток только один раз, в начале работы программы
2) использовать Queue для общения с ним: https://docs.python.org/2/library/queue.html

Альтернатива, чтобы было гораздо проще - можно использовать Celery: celeryproject.org

Позволю себе добавить к словам других комментаторов: обычно лучше не делать "громадные условия", их трудно читать. Почти всегда можно как-нибудь оптимизировать и сократить, например, разложив его на отдельные переменные, или составляя список и натравливая на него any() / all(), или вынося это всё в отдельную функцию с кучей assert, вместо условия ловя AssertionError.

Исходя из вопроса и из рассмотрения обилия библиотек как недостатка - вряд ли проблема в языке программирования. :) Python вполне хорош для всяческих скриптов и обработки данных. Я думаю, что о Scala надо думать, когда система, которую вы хотите сделать, становится настолько огромной и сложной, что без повсеместных internal DSL, систем типов и теории категорий вам с ней не выжить. Так что попробуйте всё же разобраться как следует.

Делаем с помощью notion.so - храним там базовую документацию, глоссарий понятий, очень краткие описания административных процедур, объяснения почему и как работают некоторые вещи, и конечно - документы на отдельные задачи (если задача крупная и писать полное описание в баг-трекере неудобно). Важно, что с этими документами работает сторона клиента, то есть они сами пишут задачи, вставляют туда скриншоты, etc. После чего написанное ими можно доработать, добавить разъяснения для разработчика - и в процесс.

Но вопрос документации в коде, о котором тут писали, меня сильно беспокоит; нам надо озаботиться этим. Именно для того, чтобы разработчики, особенно новые, видели в более понятном виде общую картину. Конечно, есть какая-то навигация в IDE, но всё равно это не вполне то.

Всю документацию держать в коде нельзя, по моему мнению, поскольку мы хотим привлечь клиента к работе над ней. Но и для разработчика отдельно писать код и отдельно доки - тоже проблема, лишние затраты времени и переключение контекста. Делать это никто не любит. Поэтому и думаю, что нужно иметь два комплекта документации - сугубо для разработки, автогенерированная из кода, и в базе знаний, ориентированная на клиента. Notion мне в этом смысле нравится неимоверно, ничего подобного в других местах я не видел. Хотя нет предела совершенству и хочется ещё большего :)

P. S. Евгений: по поводу literary programming... я пробовал нечто подобное делать в студенческом хобби-проекте, баловался. Но не очень получилось, поскольку линейная последовательность документа вступает в конфликт со структурой программы, имеющей вид графа.

Однако, мне доставляло изрядное удовольствие, что в результате получается не только код на Python, но и неимоверно красивый PDF, сделанный LaTeX, с картинками и формулами. А если исхитриться - можно ведь и прямо из кода всякие картинки генерировать, схемы БД например; красиво ведь будет. Надо как-нибудь вернуться к этой теме, очень уж она интересна.

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

Может быть, можно посмотреть на другие шеллы? Доходили смутные слухи, что разнообразные zsh и csh более логичны, чем bash.

Если поток один, то:

import time

while True:
    time.sleep(1) # in seconds
    action()

https://www.genmymodel.com - чуть помощнее и покрасивее, но хочет денег после некоторого количества объектов на схеме.
https://dbdesigner.net/ - денег не хочет, но попроще и менее красивый.

В долгосрочной перспективе стоит использовать Django REST Framework: djangorestframework.org

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

Я думаю, что проще всего использовать стандартную модель User + свою модель Profile, подключённую через OneToOneField. В ней можно собирать все необходимые свойства. Что мешает модератору сайта одновременно быть покупателем футболочек? Собственно ничего.

А теперь что касается проверок на is_staff. Посмотрите django-braces. Вам достаточно использовать class based views и подключать нужные mixins, - и вы забудете об этих проверках: большая их часть будет выполняться в mixins, а не в бизнес-логике предметной области. Вы можете и свои классы для этого дела написать.

1) TypeSerializer нигде не вызывается. Откуда Django знает, что вы хотите его использовать?
2) См. документацию. Вам надо, мне кажется, nested relationship. www.django-rest-framework.org/api-guide/relations/...
3) serializator - ну зачем ужас такой? На русском "сериализатор". На английском "serializer". И никак иначе.
4) Лучше уходить от views в виде функций сразу и навсегда. Используйте class based views.
5) Учитывая, что вы используете DRF и она предоставляет множество классов для этого начиная от APIView. А ещё такие удобные штуки как viewsets и routers.