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

[Steven D'Aprano]

On Fri, 23 Jan 2009 13:57:52 +0100, Bruno Desthuilliers wrote:

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

If you're messing with the internals, you have to do this anyway. As soon 
as the internals change, your monkey-patched solution falls apart.


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

That's a model that works well when you have a small team of, say, a 
dozen people. It's not a model that works when you have hundreds of 
developers working on the project. The last thing I want in my projects 
is cowboys who ride all over other people's code, changing internals of 
parts they barely know at the drop of a hat, causing who knows what side-
effects.

But anyway, this is a red-herring. Data hiding isn't really about 
managing the development process, it's about ensuring that when you and 
Fred are using Barney's OrderedDict class in your code, Barney is free to 
change his the implementation without your code suddenly failing. It's 
also to ensure that any changes you make at runtime to the class don't 
suddenly make Fred's code break.


-- 
Steven