Проблема: Есть класс, который определяет некоторое общее поведение для других классов,

и другие классы должны будут наследоваться от первого класса. Если конкретнее, то мне надо определить общее поведение, которое различается в мелочах, для нескольких джанговских тесткейсов. Различия должны быть не на уровне объектов, а на уровне субклассов, то есть у суперкласса должны быть поля, которые должны как-то быть помечены абстрактными (абстрактпроперти просто вешать на методы мне не надо, я не хочу плодить кучу однотипных методов), а субклассы должны быть обязаны предоставить настоящие значения.

Как лаконично указать, что при наследовании от какого-то класса нужно конкретизировать в субклассе некоторые поля?

а я не уверен что нужны. Вижу что просит

не понимаю зачем тут наследование вообще

Можно init сделать абстрактным и вызываьть метод для проверки наличия всех полей: import abc from typing import List class Abstract(abc.ABC): @abc.abstractmethod def __init__(self): """Forces you to implement __init__ in 'Concrete'. Make sure to call __post_init__() from inside 'Concrete'.""" def __post_init__(self): self._has_required_attributes() def _has_required_attributes(self): req_attrs: List[str] = ['attr1', 'attr2'] for attr in req_attrs: if not hasattr(self, attr): raise AttributeError(f"Missing attribute: '{attr}'")

у джанги как: есть файл в аппке с тестами (tests.py), в нём группы тестов - это классы (наследующиеся от TestCase), а сами тесты - методы этих классов, имена которых начинаются с test_. У меня есть две тест-группы, которые очень похожи, и я хочу убрать повторяющийся код, поэтому я решил, что я сделаю базовый класс с общим кодом для тестов, а потом унаследую от него (и от TestCase) два класса внутри tests.py, где просто определю то, что я не могу определить в базовом классе (потому что это как раз абстрактные вещи). Поэтому я не могу придумать что-то получше наследования. Вообще, я сейчас кое-что придумал: у базового класса теперь есть __init__, в который передаётся всё абстрактное, а иниты классов-наследников я сделал такими, что они сами ничего не принимают, зато вызывают инит от суперкласса, куда передают всё конкретное

хм...

что только не придумают, лишь бы не юзать pytest

да, с инитом норм

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

я уже лет 5 не видел проектов на джанге без пайтеста

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

ну и да, эт не "джанговские тесты" а unittest