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

[Bruno Desthuilliers]

Russ P. a écrit :
> 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.

The second is named "data hiding". And while it's a mean to _enforce_ 
encapsulation, it is not encapsulation by itself. Encapsulation is about 
making clear what's part of the public interface and what's 
implementation detail - IOW, it's about decoupling client code from 
implementation. Nothing in this _requires_ data hiding.

> 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.

You can choose to trust everything you read on wikipedia. You can... 
wrt/ what's OO, the only commonly accepted definitions are:

1/ objects are defined by an identity, a state and a behaviour
2/ objects communicate by sending messages to each other


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

Your POV.

> But the point is that if you don't like
> encapsulation, 

I do like it. What I don't like is useless language-enforced restrictions.

> 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.

Another widely accepted definition within the OO community is that C++ 
is an OO language because it has classes and data-hiding, and that 
Javascript is not because it has none of them.

> 
>> 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.

Neither. The only requirements for being an OOPL are stated above.

>> 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

You can claim it, yes. OTHO, I can claim that Java is not strictly 
object oriented since it has non-object types.

In both cases, this is just plain meaningless. There's no closed, 
well-defined theory, no mathematical model behind "OO" (like there are 
for functional programming or for the relational model). So you just 
can't apply "strictly" to OO. It's just nonsense.

>>> 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.

IOW : "this is the HolyTruth(tm), because I said so". Sorry, won't work.

>> In fact this is true, C can be seen as an programming language
>> that has features of the OO model.

Yes. And FWIW, there are OO libraries and programs written in plain C. 
Ever heard of GTK+ ?

>> 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.

For a somewhat partial definition of "good software engineering". Mine 
is that anything that leads to a correct, robuste and maintainable 
program is good engineering, anything else is not. From this POV, and 
given the proven fact that the bug/LOC ratio is nearly constant whatever 
the language, anything that adds accidental complexity makes the program 
less robust and less maintainable, and as such is _not_ "good software 
engineering". Sorry for being pragmatic !-)

>>> 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.

And ? Except that this code surely needs urgent surgery (sorry, I meant
refactoring), I don't see what the size of the project or the team has 
to do with it. You'll find successful "monster" projects written in 
languages that are even more permissive than Python (C anyone ?), and 
failed "monster" projects written in highly unpermissive languages like 
Java or ADA.