k1r3al

Но почему я не могу написать метод from_string так:

cls вместо явного Date позволит наследнику Date (напр. AztecaDate - дата по календарю ацтеков) порождать именно AztecaDate.
Кстати, есть одна тонкость, связанная с реализацией ООП на разных языках. C++ позволяет реализовать несколько разных, но одноимённых конструкторов класса с разной сигнатурой (набором аргументов), например, можно сделать так:

Date(1, 1, 2019) # конструктор с сигнатурой (int, int, int)
Date("1.1.2019") # другой конструктор с сигнатурой (str)

В питоне можно добиться подобного, но ручками, анализируя состав аргументов Date.__init__, что неудобно, громоздко и нунафиг. Уж лучше забабахать Date.from_string. Но это неизбежно в динамическом языке - ведь C++ должен знать всё про аргументы конкретных вызовов конструкторов на этапе компиляции, а мы можем в рантайм творить что угодно )))

для чего нужен staticmethod, если это уже не метод, а просто функция, и я могу вынести ее из класса.

Да, можете. Я думаю, тут действует логика лучшей читаемости и логика экономии пространства имён:

• Date._статикметод1 хоть и неочевидно что делает, но точно имеет отношение к Date
  
• При импорте from date import * вы не получите охапку непонятных имён.
  

Кстати, это не бесплатно - обращение к квалифицированному имени каждый раз создаёт дополнительный опкод LOAD_ATTR. Поэтому любители выжать максимум производительности (ну бывает полезно в глубоком цикле) используют такой трюк:

# медленно
l = []
for i in range(100500):
    l.append(i)
# чуть быстрее )))
push = l.append
for i in range(100500):
    push(i)

Попробовал через сериалайзер - вроде все работает

class DirectoryItemSerializer(serializers.ModelSerializer):

    def create(self, validated_data):
        directoryId = validated_data['directory'].id
        isActive = True
        code = validated_data['code']
        directoryItems = DirectoryItem.objects.filter(directory=directoryId, is_active=isActive, code=code)
        if directoryItems.count() != 0:
            item = directoryItems[0]
            if item.name == validated_data['name'] and item.short_name == validated_data['short_name']:
                raise EntityExistException()
            else:
                item.is_active = False
                item.save()
                return DirectoryItem.objects.create(**validated_data)
        else:
            return DirectoryItem.objects.create(**validated_data)

    class Meta:
        model = DirectoryItem
        fields = '__all__'

В общем нашёл я функцию сортировки. Сортирует она в функции get_app_list класса AdminSite. Затем по указанию Pavel Denisov стал искать способы решения. Находил разные варианты, поэтому объединив получил следующий вариант. Все манипуляции происходят в файле admin.py.
Тут сразу хочется сделать некое отступление, что при переназначении регистрации, из админки пропадают Пользователи и группы и поэтому их нужно туда зарегистрировать самостоятельно. Но обо всём по порядку.

1. Делаем необходимый импорт:

from django.contrib.admin import AdminSite
from django.contrib.auth.models import Group, User
from django.contrib.auth.admin import GroupAdmin, UserAdmin

2. Определяем свой класс, наследуясь от AdminSite и в нём переписываем функцию. (в моём случае я просто закомментировал цикл сортировки):

class MyAdminSite(AdminSite):

    def get_app_list(self, request):
        """
        Return a sorted list of all the installed apps that have been
        registered in this site.
        """
        app_dict = self._build_app_dict(request)

        # Sort the apps alphabetically.
        app_list = sorted(app_dict.values(), key=lambda x: x['name'].lower())

        # Sort the models alphabetically within each app.
        #for app in app_list:
        #    app['models'].sort(key=lambda x: x['name'])

        return app_list

3. Подменяем admin.site своим собственным:
admin.site = MyAdminSite()

4. Регистрируем своим модели:

# Register your models here.
admin.site.register(TypeProfile)
admin.site.register(TypeFacade) 
admin.site.register(Price)
admin.site.register(PaintColor)
admin.site.register(PatinaColor)
admin.site.register(Materials)
admin.site.register(Category)
admin.site.register(Products)

5. Регистрируем стандартные модели:

#Регистрируем стандартные
admin.site.register(Group, GroupAdmin)
admin.site.register(User, UserAdmin)

И всё работает как надо.
Всем спасибо.

Есть ли порог когда использование ОРМ становится неоправданым/оправданым? Где он?

ORM-ки нужня для одного конкретного типа систем - OLTP (On-line Transaction Processing)

У меня в приложении есть модуль который работает с бд Solr

У вас есть документы, в документно ориентированных базах данных нет связей. Потому вам нужен Object Document Manager а не Object Relational Mapper.

Каждый документ может имеет поле parent в котором сохранен ид-родителя, дальше ид-прародителя, дальше прапрародителя итд.

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

бд в режиме read-only

Тогда точно не нужна ORM/ODM.

Итд. Иногда какая-то дополнительная трансформация.

Но это же трансформация на уровне формирования результата выборки, так? Если так - то это опять же не та проблема.

статьи:
www.robocraft.ru/blog/ARM/
mycontroller.ru/
easystm32.ru/
ziblog.ru/category/stm32/
we.easyelectronics.ru/tag/STM32/

форумы:
electronix.ru/forum/
forum.easyelectronics.ru/
caxapa.ru/

отладочные средства:
stm32f3-discovery — наиболее подходящее решение для коптера на основе stm32 (на борту сам микроконтроллер, отладчик, гироскоп, акселерометр с магнитометром-компасом). На эту плату портирован автопилот OpenPilot

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