Does Python really follow its philosophy of "Readability counts"?
steve at REMOVE-THIS-cybersource.com.au
Fri Jan 23 14:21:39 CET 2009
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
> 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-
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.
More information about the Python-list