Форум сайта python.su
Вы вообще знаете, что такое инкапсуляция и зачем она нужна? Очень сомнительно, потому что пишете буквально, что “содержимое класса нужно открыть для редактирования извне”.
То, что это в питоне возможно, не означает, что тут же надо пользоваться этим.
Это то же самое, что сказать “в питоне можно делать глобальные переменные, значит пользоваться ими нужно и это правильно”. Примерно такая же ахинея.
Офлайн
py.user.next
Ну хорошо, я - говнокодер и не знаю питона. Давай послушаем, что на этот счет говорит Гвидо?
вот ссылка на интервью
вот конкретная цитата
About: Immutable object properties
If you want ALL the attributes to be read-only, you can use collections.namedtuple.
This sort of control over other developers is generally considered un-Pythonic because it violates the “we're all adults here” principle. If the documentation says “Don't assign to X”, you know you are taking your chances when you do it. If you feel that you have a good enough reason to do it, bully for you, but don't complain when it breaks.
One feature Python already has which violates this principle is the ‘__’ prefix name mangling. I've had the misfortune of working with a library where I really had a very good reason to change one of the “private” variables in a very safe way, but because the original developer had arbitrarily made ALL his attributes “__*”, I had to fork the library and fix it first.
Офлайн
> I came across a quote “we are all consenting adults here” I think in
> explaining why it is not necessary to have type declaration
> statements in Python, in contrast to other strongly-typed languages.
This expression is also used in the object-oriented python
literature to explain python's attitudes about private class
members, which python doesn't have.
When you create an instance of some class there is nothing to
prevent you from poking around inside and using various internal,
private methods that are (a) necessary for the class to function,
BUT (b) not intended for direct use/access.
Nothing is really private in python. No class or class instance can
keep you away from all what's inside (this makes introspection
possible and powerful). Python trusts you. It says “hey, if you want
to go poking around in dark places, I'm gonna trust that you've got
a good reason and you're not making trouble.”
After all, we're all consenting adults here.
C++ and Java don't have this philosophy (not to the same extent).
They allow you create private methods and static members.
Perl culture is like python in this respect, but Perl expresses the
sentiment a bit differently. As the Camel book puts it,
“a Perl module would prefer that you stayed out of its living room
because you weren't invited, not because it has a shotgun.”
But the sentiment is identical.
–karl
Офлайн
Оттуда же
> translation doesn't always allow me to understand the point that is
> being made (especially when there is no attempt to elaborate beyond a
> bland assertion that some code is or is not ‘pythonic’). Can anyone
> suggest some resources that have a number of code examples that
> illustrate ‘pythonic’ vs. ‘non-pythonic’ style?
Unpythonic is doing lots of type checking, or trying really hard to make
something private/protected. Or using an index to loop through a list
rather than just doing “for item in mylist”. Basically anything people do
because that's how they do it in other languages, thinking it's as good as
it gets. Code obsfucation (Perl) is unpythonic too. People you don't like
fall in the same category. It's a very broad term .
Офлайн
py.user.nextЭто вы передергиваете. Написано что если поле входит в открытый интерфейс, и на текущей стадии проекта не предусмотрено побочных эффектов от манипуляции с ним, то его надо реализовывать как открытое поле.
“содержимое класса нужно открыть для редактирования извне”.
py.user.next
глобальные переменные, значит пользоваться ими нужно и это правильно”. Примерно такая же ахинея.
Офлайн
doza_andТы его не сможешь реализовать как закрытое поле, потому что в питоне нет закрытых полей. Если бы они были в питоне, то не нужно было бы делать свойства.
Написано что если поле входит в открытый интерфейс, и на текущей стадии проекта не предусмотрено побочных эффектов от манипуляции с ним, то его надо реализовывать как открытое поле.
doza_andУ тебя интерфейс наполовину разломан, а ты даже этого не понимаешь, потому что не пользуешься им. Написал там чота и забыл.
О чем вы говорите?
Офлайн
py.user.next
Всё-таки ты решил поспорить с Ван Россумом?
Вот его электронка: guido (at) python.org
Будем ждать, что в следующем интервью Гвидо выразит в корне другое мнение по поводу pythonic way, а в следующем релизе питона появятся модификаторы доступа.
Офлайн
FishHookВот это же и относится к изменению полей извне. Он пишет про запись, но то же самое касается и чтения. Ты никак не можешь угадать, что там будет записано. Представь, что ты читаешь это поле, думая, что там одна инфа, а кто-то другой записывает в это поле свою инфу, не зная про тебя. Причём вы оба не разработчики класса, а наружние пользователи. Получается такая же хрень, как и с глобальными переменными.
If you feel that you have a good enough reason to do it, bully for you, but don't complain when it breaks.
Отредактировано py.user.next (Март 19, 2016 07:00:17)
Офлайн
py.user.nextИменно так и происходит. Более того не просто подчеркнутых, что пол беды, а записей жуткого вида
и код превращается в скопление подчёркнутых имён.
self._a=self._b+self._c
a=b+c
class Ta: def some(self): a=self._a b=self._b
def a(some,a=34,b=45): i=3 j=some*6 for ...: yield x
Отредактировано doza_and (Март 19, 2016 09:26:27)
Офлайн