Rom4eg196
баланс между постулатами Питона и ООП, разве получилось плохо?

Ответ на вопрос - по моему мнению получилось отвратительно.

Куча кода в которой с первого взгляда не разберешься и которая ничегошеньки не дает.
Тут скорее не дзен нужен а бритва оккама + здравый смысл. Попробуйте ответить на вопрос что ваша конструкция изменит к лучшему в клиентском коде и почему вам недостаточно общепринятых конструкций - полей и property.

Собственно скромное мнение:
ООП в любом ЯП остаётся ООП. Просто следует относится к постулатам более философски. Какой смысл запрещать программисту пользоваться переменными напрямую? Какой смысл скрывать методы и свойства? Это все удобно только когда пользуешься автокомплитом IDE. Когда описывают ООП, говорят - “давайте скроем от пользователя методы”. Но я блин не просто пользователь, я инженер, программист, философ : ). Я хочу видеть что внутри, я хочу иметь возможность этим воспользоваться, я хочу!
И как бы не была красива идеология, все ЯП пытаются её обойти, а потом добавляют, мол учтите, это не противоречит идеологии ООП (к примеру: ведь тут чтобы получить доступ к приватным методам, необходимо явно указать это). Это потому что теория и практика - разные вещи.
В питоне свои финты с ООП, отличные от финтов с ООП в ЯП, которые вы использовали до питона, но к ним также можно добавить присказку об отсутствии противоречий с идеологией. Почему бы не использовать их?

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