Михаил Р.

Обратил внимание, что последние пару лет все чаще слышу про fastapi, насколько он уже созрел на рынке? "Слышать" это одно (субъективщина, хайп и все такие), может есть какие-то метрики, как определять востребованность конкретной технологии относительно другой, например django и fastapi

Я придерживаюсь 2х критериев для ЯП, которые используются в малых-средний проектах, это сайт с поиском работы (hh), и фриланс площадки. Вот инфа по hh на 10.03.2025:

Без взаимоисключений:
- Django: 184 вакансии.
- FastAPI: 172 вакансии.

Взаимоисключающие django и fastapi:
- Django: 100 вакансий.
- FastAPI: 89 вакансий.

Всего пару лет назад FastAPI составлял 30% от django, сейчас же они сравнялись (тенденция на лицо), на фрилансе FastAPI так же часто мелькает, а учитывая, что это относительно django новая технология, то на него обязательно стоит обратить внимание, т.к. вполне вероятно, что его рост на рынке продолжится.

FastAPI изначально идет практически голым по функциональности, в отличие от django, т.е. разработчик должен иметь более высокую квалификацию, чтобы выполнять те же самые задачи. Скорее всего, это отразится на стоимости конечного проекта, хотя и производительность проекта будет сильно больше.

style.css:
boby{
background-color: red;
}

Точно боби, не добби? ;)

Если я правильно понял задачу, то как то так:

# MyUser
from django.contrib.auth.models import AbstractUser
from django.db import models

class MyUser(AbstractUser):
    # ...
    class Meta:
        swappable = 'AUTH_USER_MODEL'

# MyUserCreationForm
from django import forms
from django.contrib.auth.forms import UserCreationForm
from .models import MyUser

class MyUserCreationForm(UserCreationForm):
    class Meta:
        model = MyUser
        fields = ('username', 'password1', '...')

# view
from django.urls import reverse_lazy
from django.views.generic.edit import CreateView
from .forms import MyUserCreationForm
from .models import MyUser

class MyUserCreateView(CreateView):
    model = MyUser
    form_class = MyUserCreationForm
    template_name = 'registration/registration_form.html'
    success_url = reverse_lazy('blog:index')

# urls
from django.urls import path, include
from .views import MyUserCreateView

urlpatterns = [
    path('auth/', include('django.contrib.auth.urls')),
    path('auth/registration/', MyUserCreateView.as_view(), name='registration'),
]

Или есть какое-нибудь другое решение?

Для Вашей задачи можно использовать сигнал post_delete, чтобы автоматически удалять связанные файлы из модели File, когда удаляется объект модели Question.

Возможно ли засунуть django в сайт написанный на bitrix 1c?

Возможно. Нужно ли? - нет.

Возможно ли написать бекенд для мобильного приложения на андроид и iOS на Django Python?

Возможно.

Если да, то что нужно для этого поизучать

Все тоже самое, что и для разработки бэка для любого другого проекта.

и на чем писать фронтенд для мобильного приложения?

На чем умеете, но вот список от простого к сложному:
- React Native.
- Flutter.
- Kotlin/Swift.

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

Если прям жмет, то можно разместить __init__.py в каждом каталоге до консольной команды, с импортом вида:

from .command1 import Command1

# app/
#    management/
#        __init__.py <-- this import
#        commands/
#            __init__.py <-- and this import
#                command1/
#                    __init__.py <-- and this import

Это позволит Django обнаруживать команды, находящиеся в подкаталогах, но при этом требует, чтобы каждая команда была в своем собственном подкаталоге и имела собственный __init__.py.

Кстати, имя команды которое Вы используете при вызове manage.py, должно соответствовать имени каталога, в котором находится команда. Соответственно, если Вы разместили команду в app/management/commands/subdir1/command1, Вы всё равно вызываете её как manage.py command1, не указывая subdir1. Django не поддерживает вызов команд с использованием точечной нотации для обозначения подкаталогов, как в Вашем примере subdir1.command1.

Короткий ответ (с учетом указанного ТЗ) - WP.

Длинный ответ:

публиковать страницы, создавать иерархию страниц, чпу url, какой то слайдер с картинками

Учитывая типовое ТЗ, ответ - WP (все это уже реализовано, преимущественно бесплатно и в большом количестве).

небольшое количество услуги в регионе

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

Нашли компанию, предлагает разработку сайта на WP или на Python+Django (дороже и дольше)

Начнем с того, что это не равнозначные инструмент, ибо WP - это готовый движок/CMS для сайта + сам сайт (готовые шаблоны), развернул на хостинге и готово. А вот Django - это фреймворк, т.е. некий набор инструментов, да он позволяет сделать из него что угодно (ах*енно сделать (на правах отвечающего)), но потом. Соответственно, если вопроса в функционале и производительности не стоит (и предположу - сделать быстро) - выбираем WP, будет дешевле и быстрее.

Что обычно я использую (от начального проекта к финальному):
1. WP в стоке + сборка фронта (webpack) с оптимизацией + кэширование.
2. Докупка железа и горизонтальное масштабирование п1 балансировщиком.
3. Профилирование и переписывание определенных запросов под конкретные задачи в самом WP, обычно добавляет производительности в 2-3 раза (от wp там мало что остается, но ценник и сроки еще не такие, как в п4).
4. Python + Django + кэширование (если нужно быстрее любого WP и более специфический функционал).
5. П4 + FastAPI (если прям совсем прижало по производительности).

# STATICFILES_DIRD = [os.path. join(BASE_DIR, 'static')]
STATICFILES_DIRS = [os.path.join(BASE_DIR, 'static')]

Результат?