Anyway, it doesn't matter. We're losing the point here. The point is
that language support for private access, by disallowing user access
to private data, provides an unambiguous information hiding mechanism
which encourages encapsulation. Python's approach, however, which is
only a naming convention rather than a language feature, merely TRUSTS
the programmer not to break encapsulation. And sure, if we're all good
programmers, everything will go well and we'll end up with an
organized application. But the danger is still there: at any given
time, we COULD break encapsulation!
I was long-winded the last time I responded to this point so no one probably read it :)
But to be concise: So what?
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.
There is no actual "danger".
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.
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.
--S
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list
