Methods vs. Functions (Re: [Python-Dev] A house upon the sand)

[Barry A. Warsaw]

>>>>> "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