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

[Russ P.]

On Jan 23, 4:57 am, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> Russ P. a écrit :

> > As I said before, if you have the source code you can always change
> > private attributes to public in a pinch if the language enforces
> > encapsulation.
>
> And then have to maintain a fork. No, thanks.

For crying out loud, how many private attributes do you need to
access? If it's a dozen, then you and your library developer are
obviously not on the same page. If it's one or two, then it's hardly a
"fork." Just take note of the one or two places where you needed to
remove the access restriction and you're done. Heck, you don't even
need to do that, because you will be warned automatically anyway when
you get the new version of the library (unless those private
attributes are changed to public).

> > But if you are working on a team project, you can't
> > change the code that another member of a team checks in.
>
> Why on earth couldn't I change the code of another member of my team if
> that code needs changes ? The code is the whole team's ownership.

OK, fine, you can change the code of another member of the team. Are
you going to check with him first, or just do it? The point is that
changing an interface requires agreement of the team members who use
that interface, whether on the calling or the implementation side of
it. If you change interfaces without getting agreement with the other
team members, you probably won't be on the team for long. And without
access restrictions, accessing _private is equivalent to changing the
interface.

> Now and FWIW,  in this case (our own code), I just don't need to "mess
> with internals" - I just just change what needs to be changed.
>
> > That is how
> > enforced data hiding helps teams of developers manage interfaces.
>
> I totally fails to find any evidence of this assertion in the above
> "demonstration".
>
> > The
> > bigger the team and the bigger the project, the more it helps.
>
> Your opinion.
>
> > Mr. D'Aprano gave an excellent example of a large banking program.
> > Without enforced encapsulation, anyone on the development team has
> > access to the entire program and could potentially sneak in fraudulent
> > code much more easily than if encapsulation were enforced by the
> > language.
>
> My my my. If you don't trust your programmers, then indeed, don't use
> Python. What can I say (and what do I care ?). But once again, relying
> on the language's access restriction to manage *security* is, well, kind
> of funny, you know ?

Are you seriously saying that if you were managing the production of a
major financial software package with hundreds of developers, you
would just "trust" them all to have free access to the most sensitive
and critical parts of the program? Now *that's*, well, kind of funny,
you know?

Would you give all those developers your password to get into the
system? No? Wait a minute ... you mean you wouldn't "trust" them with
your password? But what about "openness"? Are you some sort of fascist
or what?