Why does python not have a mechanism for data hiding?

alex23 wuwei23 at gmail.com
Wed Jun 4 04:37:17 CEST 2008


On Jun 4, 4:29 am, "Russ P." <Russ.Paie... at gmail.com> wrote:
> If you think that private data and methods should not be allowed
> because they complicate unit testing, then I suggest you take a look
> at how unit testing is done is C++, Java, and Ada. They seem to do
> just fine.

Nice to put the burden of evidence back onto everyone else, but doing
a bit of searching I found the following "answers" to the question of
unit-testing private functions & methods:

> I suggest that tests should be written only for the public methods.

> You can use a debugger, probably Carbide. That way you can see
> all the variables. Otherwise, write the values to a log or EMCT.
> You can make the logging only happen for debug builds if you don't
> want the logging in the production code. If you really need to
> see the private variables from your code, declare them public in
> debug builds.

> Problem is testing private functions. Some can be fixed by
> promoting private to protected, inheriting the class adding
> testing in the class. Others get refactored out the classes
> they reside in and get put into their own functor classes[...]

So the basic answers I'm seeing that "do just fine" are:

1. Don't test private functions.
2. Add functionality _to_ the private functions for testing.
3. Change the interface for the purpose of testing.

All of which seem exceptionally inefficient and run counter to the
whole purpose of unit testing.

> But I think there is a more fundamental issue here. You complain about
> problems with software that uses data encapsulation. So two
> possibilities exist here: either the designers of the code were not
> smart enough to understand what data or methods the client would need,
> or the client is not smart enough to understand what they need. Maybe
> the solution is smarter programmers and clients rather than a dumber
> language.

This is the most ludicrous argument I've ever heard. Of _course_ we
can't predict every possible usage of our code that others might want
it for. If someone can easily extend code that I've written to improve
or increase its functionality, why would I want to prevent them from
doing so?

Then again, I tend to think of other programmers as "peers" rather
than clients. YMMV.



More information about the Python-list mailing list