"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> I disagree. While non-methods *can* look inside an GvR> implementation, it's still implied that they break GvR> encapsulation if they do. (This may explain why you like to GvR> use private names -- they make the encapsulation explicit. GvR> For me, it exists even when it is implicit.) True, but it still means that changing the implementation has an unknown effect on existing code, because there /could/ be a lot of breakage. That can be (and has been! :) written off as the fault of the 3rd party author, but still, it isn't enforcible like it is in C++, where, if it ain't a friend, it's not going to break. In C++ you can count the number of functions that will break to determine the degree of encapsulation, but you can't in Python. Witness the recent change to cgi.FieldStorage. We removed the self.lines attribute because it was a memory bloat, and we /thought/ that it wouldn't affect existing code, but there was no way to really know for sure because the intent of the cgi module author wasn't at all clear. Was self.lines intended to be public but just accidentally undocumented? Was it a debugging tool? As an aside, this argument's not really true with built-in types such as strings because the internal implementation isn't publically available to the Python programmer. -Barry