<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Anyway, it doesn't matter. We're losing the point here. The point is<br>
that language support for private access, by disallowing user access<br>
to private data, provides an unambiguous information hiding mechanism<br>
which encourages encapsulation. Python's approach, however, which is<br>
only a naming convention rather than a language feature, merely TRUSTS<br>
the programmer not to break encapsulation. And sure, if we're all good<br>
programmers, everything will go well and we'll end up with an<br>
organized application. But the danger is still there: at any given<br>
time, we COULD break encapsulation!<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>I was long-winded the last time I responded to this point so no one probably read it :)<br><br>But to be concise: So what?<br><br>If you believe encapsulation should never be broken: don't do it! If your corporation believes encapsulation should never be broken, the code review process (you do have one right?) will catch it and you can fire the person for not following policy. If your open source project believes encapsulation should never be broken, the code review process (you do have one right?) will catch it and you can chastise for not following policy and reject the patch. <br><br>There is no actual "danger". <br><br>The convention is unambiguous. If you believe encapsulation should be absolute, you can have that very easily: don't play with anyone else's privates.<br><br>The *idea* of encapsulation is good in many cases, it is quite often a solid design point and admirable goal. The *implementation* of enforced data encapsulation brings no value to any realistic situation.<br><br>--S<br></div></div><br>