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

[Russ P.]

On Jan 13, 7:32 pm, "James Mills" <prolo... at shortcircuit.net.au>
wrote:
> On Wed, Jan 14, 2009 at 1:18 PM, Russ P. <Russ.Paie... at gmail.com> wrote:
> > 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.
>
> Wrong. Not having strict and enforced access control 9_NOT_ encapsulation)
> (Please stop confusing the two) is not a strict requirements of the OO model.

I think you are the one who is confused. Part of the problem here is
that the term "encapsulation" has at least two widely used meanings
(in the context of programming). In one sense, it just means grouping
data and methods together. In another sense, it means restricting the
client's access to data or methods. Someone earlier on this thread
tried to claim that the first meaning applies to OOP, but Wikipedia
(and many other sources) say just the opposite.

People here are trying to claim that the leading underscore
conventions used with Python are essentially equivalent to
encapsulation. That is nonsense, of course.

Others are arguing against encapsulation altogether. That is a bit
like being against locks or passwords because they create a lot of
hassle. Now locks are not needed everywhere, of course, but certainly
they have their place. But the point is that if you don't like
encapsulation, then by definition you don't like OOP. You may like
certain features of OOP, but you don't like it in general. That's
about all their is to it.

And by the way, please don't bring up the canard that I am some kind
of OO zealot. I think OO is overrated, and I don't Java, in part
because it forces everything to be OO. The issue here is not my
personal opinion of OOP. This issue is one of widely accepted
definitions within the OO community.


> Remember that it is a model and not a strict set of requirements that
> programming
> languages must implement.

Of course it's not a "requirement that programming languages must
implement." It's only a requirement if they want to be OO languages.

> In fact, Python borrows features from the Functional Paradigm. Does this
> make it a Functional Language ? No. Why ? Because one of the clear
> requirements of the Functional Paradigm is that functions cannot have
> side affects.
>
> > 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.
>
> In fact this is true, C can be seen as an programming language
> that has features of the OO model.
>
> I think one of the things you guys are missing out
> here is that there are really only two Paradigms
> or Machines. Functional and Imperative. And guess
> what ? As it turns out we can implement functional
> machines that run on top of imperative ones!
>
> > 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."
>
> Again, stop confusing terminology.
>
> Should Python get strict and enforce access control
> of object members ? No. Why ? I can think of several
> reasons.
>
> Give me one use-case where you strictly require
> that members of an object be private and their
> access enforced as such ?

You're kidding, right? Think about a ten-million line program being
developed by 100 developers.