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
О чем вы говорите?

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
и код превращается в скопление подчёркнутых имён.

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