On Jan 23, 4:57 am, Bruno Desthuilliers <bruno. 42.desthuilli...@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? -- http://mail.python.org/mailman/listinfo/python-list
