ООП сейчас не все используют⁠⁠

Безусловно соглашусь. Но  индустрия отошла от изначального понимания - это факт. Поэтому сошлись на трёх китах и ладно.

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

Короче, терминологические споры могут быть злом. Определите понятие "понятие", как это бесило в философии

Договорённостей вполне достаточно для того, чтобы писать код, так что предлагаю считать, что сокрытие в Питоне есть. Сложившаяся практика важнее наличия фич мне кажется.

Утверждаю, что определение "инкапсуляция - это сокрытие данных" неверное. Понятно, что скрывать нужно и у этого есть свой смысл, но главным я считаю объединение данных и методов работы с ними.

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

Питон - мультипарадигменный. Там можно как угодно писать.

Ты сейчас имел в виду именно свободную функцию? Не метод? Функцию, которая по разному работает, когда в неё передают объекты разных типов? Тогда это совсем не ООП, а в лучшем случае параметрический полиморфизм.

Да, len - параметрический полиморфизм, но полиморфизм же. Тогда приведу пример переопределения сложения или любых других методов.

Или что я могу любой класса превратить в iterable тип, и внешний код сможет for obj in my_class делать.

Ладно, прикладной пример из недавнего. Есть группа проектов студентов, в каждом должны быть формальные файлы с фиксированными именами. Штука в том, что в некоторых проектах имена отличаются (условно, два варианта есть). Так вот, чем в код тащить if project_type == 1 делаем то-то, я делаю два класса-обработчика - Handler1 и Handler2. Метод process наследуется у BaseHandler и не трогается, а вот список файлов вынесен в поле Handler1 и Handler2.

Ты слышал про ECS? В Unity вроде в полный рост практикуется. В Питоне в геймдеве этот подход не используют?

Не, я не про gamedev, вспомнил просто оттуда пример. Про ECS не знал, почитаю, спасибо https://habr.com/ru/company/mygames/blog/590953/

Угу, всё публичное. Можно через подчёркивание _name сделать рекомендацию "не лезь туда" или через __name слегка осложнить использование переменной.

А так динамически делай что хочешь

да, пишу автотесты и участвую в развитии АТ-фреймворка.

у меня там статусы пациентов, которые группируются и заполняются на основе отделения которое приняло больного, имеют разные поля в зависимости от того обследуется человек или лечится, но одни и те же действия "принимаем--обслуживаем-переводим в другое своё отделение-даём направление в другое учреждение-выписываем".
Есть события рабочей смены, вида отгул-стандартная смена-ночная-сверхурочные-больничный-дежурство. Интерфейс у них один на всех, предок общий ибо три поля(день, время-начало, время-конец) есть у всех. Потом кстати более разветвлённое наследование, потому что и дальше можно группировать. Но действия у всех одни.

У меня до пизды классов из трёх-пяти полей и этак пяти методов, потому что с точки зрения бизнеса всё довольно просто, список систематически проверяемых значений небольшой, часть полей проверяется в 70 тестах и идёт в DTO, часть в 7 и проверяется непосредственно в тесте. А ещё для некоторых проверок я в очень упрощённом виде копирую полноценную работу приложения, например чтобы свериться что разрабы считают надбавку за сверхурочные по правильной формуле.

Ну и отдельные сто грамм про DTO. DTO - охуенная тема. В API тестах пишешь хороший годный DTO, может даже нагло копируешь у разрабов. Ответы с бэка в него парсятся просто отлично, пихать весь DTO в асёршен вместо построчной проверки по полям волшебно. Переиспользовать его для создания более сложных объектов и передачи части полей сразу в другой объект куда удобней чем ковырять построчно или писать методы-уродцы на 3-5 параметров. Потом берёшь и цепляешь API-репо как зависимость к UI. Этот же DTO используешь для парса объектов с UI, потому что это тот же бизнес-объект, просто представленный в ином формате. У тебя везде одинаковый объект для работы с некой бизнес-сущностью, даже полный дегенерат не сможет забыть проверить поле или заполнить его неправильно, потому что или получит эксепшеном в консоль, или будет трахаться с падающим асёршеном на дебаге. Если заказчик и как следствие приложение отказались от поля, поменяли формат, нассали в тапки, всё чинится в одном месте, а не во всех автотестах.

и да, можно пихать гиен в кошек(не буквально). Пока разделение идёт на уровне кошки/собаки, я не буду ебать себе мозги с строгой терминологией и буду называть кошкобразных - кошками, а собакообразных - собаками. Птица так-то тоже слишком широкий термин, но пока он применим - нехер усложнять. Вот если придётся виверровыми оперировать, вот тут придётся брать более детальную абстрактную модель.

...и объяснять джунам что такое виверровые.

Биолог скажет что у человека есть сложное наследуемое неосознанное поведение которое как можно назвать инстинктом, так как оно присутствует, так и можно назвать чем-то более сложным, так как с возрастом или по иным причинам это поведение замещается иными реакциями.
Эталон как-бы инстинкта у человека - стадное поведение у детей, тут впрочем орангутанги являются исключением, которое и не позволяет оперировать термином инстинкт.

Это устаревшее понятие, которое в силу появления более детальной типизации уже плохо подходит для описаний. Тот же биолог может сказать что крик младенца это инстинктивное поведение, но! И вот это "но" потребует более узкого понятия.