Encapsulation unpythonic?

[Chris Angelico]

On Sat, Aug 17, 2013 at 10:22 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 8/17/2013 11:50 AM, Chris Angelico wrote:
>>
>> On Sat, Aug 17, 2013 at 1:26 PM,  <fsaldan1 at gmail.com> wrote:
>>>
>>> 2) If it is in fact true that encapsulation is rarely used, how do I deal
>>> with the fact that other programmers can easily alter the values of members
>>> of my classes?
>>
>> Very simply: You accept it. Let them! It's their responsibility.
>
>
> When a project has multiple programmers, there is a possibility that module
> C could monkeypatch module A in a way that breaks existing user module B.
> But it is still the collective responsibility of the respective users or
> project manager to assign responsibility for fixing the conflict.

Yep. I would say there that the responsibility is with module C's
programmers; they are the ones breaching encapsulation, ergo it's
primarily their responsibility to both test this (against current
usage) and thoroughly document it (against future changes).
Personally, I would like to see a comment in module A that says
something like "NOTE: This {function|attribute|spam} is replaced
externally under [some circumstance]. Changes to its purpose may
affect Module B." to make it clear what's going on. At that point, of
course, it stops being monkeypatching and becomes documented and
official behaviour, so maybe that's not really an argument in this
example.

ChrisA