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

[Bruno Desthuilliers]

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


May I remind you that this is an hypothetical use case ?

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

Yeah, fine. And doing it each and any release. A fork is a fork is a fork...


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

No. I can change the *team's* code. Please *read*. "team's ownership", 
ok ? Or do I have to spell it out loud ? TEAM'S OWNERSHIP. Uh. You get 
the message, now ?

> Are
> you going to check with him first, or just do it?

<despair>I give up.</despair>

(snip)

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

A remote web service - for example - is a far better blackbox when it 
comes to this kind of "sensitive and critical parts". If I can't trust 
someone wrt/ "this" part of the code, then he won't even have it as a 
binary package. Period.

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

Goodwin point. You loose. Good bye again, Mr P.