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

[Bruno Desthuilliers]

Russ P. a écrit :
> On Jan 18, 9:22 am, Bruno Desthuilliers
> <bdesth.quelquech... at free.quelquepart.fr> wrote:
> 
>> Properties by themselves are not the problem, quite on the contrary - as
>> you say, they actually help wrt/ encapsulation. What breaks
>> encapsulation is *automatic generation* for properties for *each and
>> any* implementation attribute. Might as well just makes them all public
>> attribute then.
> 
> Let me correct my statement about the automatic generation of
> properties in Scala: it is only for public attributes, not all
> attributes.

I must be missing the point : if it's a public attribute, it doesn't 
need a "property" ? I guess we use the same words for different things here.

> 
> Getting back to the bigger point, I will gladly agree with you that
> data hiding is not a magic bullet that will eliminate all bugs. The
> idea that I or anyone else said that, however, is a red herring. Data
> hiding is just one safeguard in a portfolio of safeguards that can
> *help* to prevent certain kinds of bugs

s/data-hiding/encapsulation/ and I'll wholefully agree.

> as well as deliberate acts of
> sabotage or fraud.

I definitively wouldn't bet my ass on language-level access restriction 
to protect software from fraud or sabotage.

> When you have a tough problem to solve, you need
> all the help you can get.

As far as I'm concerned, *enforcing* access-restriction is of no help.

> You keep saying that if you hire competent, trustworthy developers,
> you don't need data hiding.

Yes. And I also think that trust (and even - to a certain extent - 
competence) is better built on trust than on distrust. When treated as 
an irresponsible morons just barely able to type code, most peoples tend 
to become just that : code-monkeys.

> Well, maybe, but when you have a team of
> dozens or hundreds of developers, your chances of avoiding any bad
> ones is zero for all practical purposes.

I don't know how many developpers work for google, but I bet there all 
smart enough to not need enforced access restriction. Very few people 
have a burning desire to shoot themselves in the foot, you know.

Take some not-that-trivial projects like Zope/Plone. There are quite a 
few lines of code involved, and quite a lot of programmers worked on it. 
  Some of them being very average joe programmer FWIW. Guess what ? From 
experience, it JustWork(tm). Granted, this is not a critical system - 
but that's not the point here. The point is that _from experience_, most 
programmers are wise enough to avoid doing stupid things.


> And even if all your developers were excellent, data hiding would
> still be a convenient mechanism to simplify their jobs  so they can
> focus on higher level problems

Sorry, but this makes no sense. How could the lack of 
*language-enforced* access restriction  makes anything more complicated ???


> -- and not have to rely on an ugly
> naming convention.

And here we are, finally : *you* don't like this convention (and we've 
aready been thru that discussion IIRC).

Guess what ? As far as I'm concerned, I just *love* this convention. 
Because I *never* have to ask myself if some attribute is interface or 
implementation.

> Now, if developers become careless because they think data hiding will
> save them, then that would be a problem.

If you believe data-hiding will protect your code from fraud, sabotage 
or any other malevolence, then you already have this problem IMHO.

> That much I will concede. But
> I doubt that happens much.