Does Python really follow its philosophy of "Readability counts"?

[Russ P.]

On Jan 13, 6:04 pm, "James Mills" <prolo... at shortcircuit.net.au>
wrote:
> On Wed, Jan 14, 2009 at 11:50 AM, Russ P. <Russ.Paie... at gmail.com> wrote:
> > Here's the definition on the Wikipedia page for object oriented
> > programming (and it does *not* sound like Python classes):
>
> > Encapsulation conceals the functional details of a class from objects
> > that send messages to it. ... Encapsulation is achieved by specifying
> > which classes may use the members of an object. The result is that
> > each object exposes to any class a certain interface — those members
> > accessible to that class. The reason for encapsulation is to prevent
> > clients of an interface from depending on those parts of the
> > implementation that are likely to change in future, thereby allowing
> > those changes to be made more easily, that is, without changes to
> > clients. For example, an interface can ensure that puppies can only be
> > added to an object of the class Dog by code in that class. Members are
> > often specified as public, protected or private, determining whether
> > they are available to all classes, sub-classes or only the defining
> > class. Some languages go further: Java uses the default access
> > modifier to restrict access also to classes in the same package, C#
> > and VB.NET reserve some members to classes in the same assembly using
> > keywords internal (C#) or Friend (VB.NET), and Eiffel and C++ allow
> > one to specify which classes may access any member.
>
> You do realize this is a model and not
> strictly a requirement. Quite a few things
> in Python are done merely by convention.
>
> Don't get caught up.
>
> --JamesMills

Yes, but the fact that you can approximate OO programming in a
particular language does not make that language object oriented. You
can approximate OO programming in C, but that does not mean that C is
an OO language.

So I can claim that Python is not strictly object oriented until it
gets encapsulation (in the sense of data hiding). That is simply a
fact, and no amount of pleading or obfuscation will change it.

Should Python get true encapsulation? I don't know. Maybe
encapsulation cannot be added without excessive overhead or without
compromising other more important aspects and features of the
language. But I do know that not having encapsulation is a limitation
to the use of Python for good software engineering. I may be in the
minority in the Python "community" on this one, but I am apparently in
the majority in the OO programming "community."