Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> writes: > On Wed, 04 Jun 2008 15:55:38 +1000, Ben Finney wrote: > > > By definition, "private" functions are not part of the publicly > > documented behaviour of the unit. Any behaviour exhibited by some > > private component is seen externally as a behaviour of some public > > component. > > But only indirectly
No, that's the point: externally, such behaviour is exhibited by the public API. Whatever internal moving parts actually lead to the behaviour doesn't make any difference: it's the external behaviour that's being discussed in the above. > and it's often harder to predict the corner cases that might trigger > bugs or to test error testing in dependent private functions. Indeed. The person writing the unit tests should do so with full knowledge of what the implementation looks like. This allows coverage of those corner cases you rightly point out exist in many implementations. Those unit tests should *not*, though, exercise anything but the public API, otherwise they're breaking encapsulation. Their assertion should continue to be just as true after a refactoring of the internal components as before. > Private functions offer an API that's public to someone, so they > ought to be documented and tested. No, that's pretty much the point: private functions are intended for use by nothing except other functions at the same scope. If they're to be used in other contexts, they're public API, not private. It's a feature of Python that such bad API design doesn't lead to hideous workarounds: one can still easily get at the parts of an API that the programmer mistakenly marked "private". That doesn't make it any less a mistake to break encapsulation, but it does make it much more easily fixed. -- \ "During the Middle Ages, probably one of the biggest mistakes | `\ was not putting on your armor because you were 'just going down | _o__) to the corner.'" -- Jack Handey | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list