kazmiruk

.otherwise({redirectTo: '/'}); попробуйте убрать

https://docs.djangoproject.com/en/dev/ref/applicat...

Почитайте внимательно в документации что делает modelformset_factory (djbook.ru/rel1.6/topics/forms/formsets.html#formsets) Здесь он явно не нужен. Просто импортируете Вашу форму во вьюхе и используете ее.

1.8 сейчас в продакшене, на 1.9 - уже мигрировали, проводим тестирование, пока никаких нареканий нет. Если у людей что-то не работало, то они просто не умеют ее готовить. Разработчики джанги очень ответственно относятся к релизам, прошли все миграции с 1.6 версии до 1.9 - никаких проблем. Читали changelog и меняли места, затронутые в релизе.

если мы делаем так
from django.db.model import Model
то пишем
class MyModel(Model):
....
если
from django.db import model
то так
class MyModel(model.Model):
....

Я бы сказал, что нет. Из того, что бросилось при беглом просмотре кода - абсолютные пути в settings, несоблюдение pep8 (завершаюший отступ, длина строк. Я сам не считаю, что 80 символов это нормальное значение, но строка в 146 символов это слишком много, хотя бы 120). Нет ни одного теста, импорты выполнены в перемешку, каждый метод модели с декоратором property (не очень вникал в код, может и имеет смысл, но в таком количестве вряд ли), не используете CBV, хотя кое где это уместней, не понятно смысл создания целого аппа ради хранения одной функции в 1 строчку кода, есть явное непонимание того что и где содержится (Profile.objects.create(user=User.objects.get(id=request.user.id)), User.objects.get(id=request.user.id)), не понимание что какие запросы делают (sum([x.total for x in request.user.outlays.filter(type=2)])). Также не увидел нигде индексов, возможно они действительно и не нужны (по коду в основном везде выборки по PK и FK вроде). Нет try\catch для get блока хотя кое-где может плюнуть DoesNotExists (kwargs['inviter'] = User.objects.get(id=data['inviter']))
В общем много косяков.
А вообще, по такому коду трудно судить какого Вы уровня, так как в принципе ничего специфичного там нет, даже не знающий джангу напишет такое погуглив пару дней\часов.
Советую Вам ознакомиться с pep8 подробней + установить себе pep8 и\или pylint, прочитать хотя бы two scoops of django, попрактиковать написание тестов, изучить selenium. Без обид, но пока я бы Вас не взяли на миддла, так как много бы пришлось объяснять и менять за Вами.

Мое личное мнение - взял бы python, так как php и Symfony2 в частности приводят к рвотным позывам. Но каждый кулик, как известно.
На Вашем же месте я бы проинтервьюировал каждую из команд и узнал почему они выбрали django+python, какие плюшки в сравнении с symfony2 (и наоборот), какие сопутствующие технологии собираются использовать, почему именно их и т. п. А потом бы выбрал тех, кто может адекватно ответить на эти вопросы. В любом случае оба инструмента позволят Вам добиться приблизительно одинакового результата, а вот опыт и компетентность команды решают.

Джанга тут не при чем. Делаете апи (django-rest-framework можно использовать), а затем яваскриптом отслеживаете скролл на странице. Как только скролл подошел к нижней границе - вызываете апи с запросом на следующую порцию данных. Получив данные отрисовываете их.

Как не крутите у Вас буде 1млн итераций, что много. Из более-менее реальных вариантов - вынести этот код из шаблона (генерировать плоский список в контроллере, а затем прокидывать его в шаблон). Т.е. в результате у вас должно быть что-то типа:

{% for el in l %}
<span>{{o1.n}}</span>
{% if el.flag1 %}
...
{% if el.flag2 %}
...
{% endif %}
{% endif %}
{% endfor %}

Хотя шаблоны и компилируются, но в целом выполняются медленнее, чем код. После того, как вы получите метод, генерирующий такой список - кешируйте список (или можно даже закешировать кусок шаблона со списком). Судя по всему это что-то типа хлебных крошек категорий и часто меняться не должен. Так как рендеринг в 3 секунды - ад, то при сбросе кеша этот список надо сразу помещать назад, чтобы не заставлять пользователя ждать. Т.е. должно быть как-то так: сгенерировали новый список, атомарно заменили старый список на новый. Возможно есть еще варианты оптимизации кода (например преобразование списков в словари, исключение повторений в проверках и т.п.)
Также можно извратиться обертками - не делать полный перебор, а сделать метод, который будет применять бинарный поиск к списку, к примеру. И Вы получите не O(N), а O(log2N). Но опять же тут надо смотреть применимость к Вашему коду.

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