py.user.next
В том-то и дело, что внутренние поля не входят в интерфейс

Вот в этом и есть всё противоречие нашей беседы. Публичные поля объекта входят в его интерфейс (иначе вообще нет никакого смысла в скрытых полях и методах). Ты можешь сделать поле приватным и таким образом исключить его из интерфейса, предоставив пользователю взамен методы для его получения/изменения. Но до тех пор, пока логика получения/изменения этого значения не отличается от простого чтения/присвоения переменной практического смысла в таких интерфейсах-обёртках нет, за исключением случаев, когда нам надо в критическом месте кода гарантировать доступность поля только для чтения. Когда код подвергается изменению и если в результате этих изменений вдруг становятся ненужными какие-то поля, то обертки не помогут сохранить совместимость. Если зачем-то надо переименовать поле, мы просто добавляем проперти с прежним именем, ТО ЕСТЬ ДЕЛАЕМ ТО ЖЕ ЧТО И ТЫ, ТОЛЬКО КОГДА ЭТО ПОНАДОБИЛОСЬ.

Есть общепризнанная практика, помечать поля необходимые только для внутренней работы алгоритмов одним начальным подчеркиванием. Это памятка пользователю “Сюда лучше не лезть, потому что в дальнейшем я могу это убрать из кода”.
Однако, иногда необходимо заставить чужую библиотеку работать не совсем так, как планировали авторы. Например, документированные фичи ОРМа Джанго, не всегда обеспечивают необходимый функционал и гибкость. Тогда мы можем на свой страх и риск поломать совместимость с будущими релизами и заюзать недокументированные возможности, и делать какие-то такие хреновины . Если бы _meta была скрытым полем, мы бы не сделали ничего, вместо “не очень хорошо”.

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

Да, мой код не идеален, но смотри, что там происходит.

Клаcc PropertyOfTV имеет min_value, max_value, value как приватные поля, при этом min_value max_value, защищены от изменения, а само value, изменяется только по определённым правилам.

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

То есть по сути мы расширяем PropertyOfTv, изменяем его поведение. Но при этом, вкусный и хорошо отлаженный класс, таким и остаётся, и сломать программу не получится.

Чаще всего до тех пор пока какой-нибудь дядя Вася с кривыми руками в него не влезет.

А вот если придёт нормальный разработчик, которому например надо будет добавить ещё один переключатель с новым поведением, то даже если он первый раз видит эту программу, то, потратит 5 мин, что бы найти точку входа, и 10 мин, что бы написать новый класс, и при это не найдёт проблем на свою голову.

Тоесть выгода на лицо.

Ах, да.

Если понадобиться изменить реализацию класса PropertyOfTv, или Swith то даже тот добавленный посторонним человеком переключатель, всё равно будет работать без багов - это то о чём вам говорил py.user.next.

Nab
ты не понимаешь просто

да иди ты к чёрту

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

FishHook
Вот в этом и есть всё противоречие нашей беседы. Публичные поля объекта входят в его интерфейс

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

FishHook
Ты можешь сделать поле приватным и таким образом исключить его из интерфейса

Не, я делал так, получается сплошное уродство. Пройденный этап, в питоне всё открыто, но это не значит, что это надо использовать. В хелп они включаются, но это тоже для внутреннего использования подходит, а наружний пользователь не должен на это полагаться.

То есть нарушается инкапсуляция.

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

Не, напиши так несколько классов - увидишь. Это полностью инородное для питона, поэтому код выглядит просто ужасно.

FishHook
Тогда мы можем на свой страх и риск поломать совместимость

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

py.user.next
программист снаружи поменяет это значение прямо в процессе работы экземпляра (он-то не знает, что там что-то завязано).

А что ему помешает сделать то же самое через свойства или методы? Ты не можешь делать всё до чего может дотянуться пользователь доступным только для чтения, потому что в питоне нет модификаторов protected и friend, таким образом ты не сможешь нормально наследовать свои классы и иметь внутри них доступ к приватным полям (как это сделано в нормальных языках, использующих уровни доступности). Получается либо излишнее усложнение и тотальное огораживание либо нарушение принципов инкапсуляции.

FishHook
А что ему помешает сделать то же самое через свойства или методы?

Как он пролезет через методы? Попробуй, залезь в int() через её вызов.

Я вполне четко описал свою позицию насчет свойств только для чтения. Повторяться не вижу смысла.

Nab
FishHook, ты не понимаешь просто зачем оно вообще надо

Это вы уважаемый не понимаете.

FishHook
Я вполне четко описал свою позицию

Полностью поддержу FishHook, все кристально ясно. В очень многих случаях в ПУБЛИЧНЫЙ интерфейс входит открытое свойство. Т.е. разработчик не накладывает никаких ограничений на его изменение. Что тут непонятного? Таков замысел автора. На устойчивость и расширяемость это никак не влияет как отлично показал FishHook.