Paul Rubin schrieb: > Duncan Booth <[EMAIL PROTECTED]> writes: >> The problem is that when people design interfaces they don't (and >> cannot) know all the situations in which the code is going to be used in >> the future. Clearly separating the published interface from the >> implementation details is a good thing, but physically preventing access to >> those details is IMHO a bad thing. > > The idea is to make the implementation details independent from the > calling program. For example, I'm using a library now that does > something highly CPU intensive. To speed up the application, I may > put the library on a completely separate computer, so that the > published API exposed to the caller becomes a wrapper for a network > client, and all those library implementation details are on the other > machine. That's the ultimate in physical access prevention, there's > good reason to do it, and it completely breaks if the calling program > is using anything except the published API.
So what? This will happen under under circumstances as well. Think of an interface returning None in an earlier version, then [] to indicate an empty result-set. the point is that privacy is good to indicate that "you shouldn't mess with this unless you know what you do, which includes not to use new versions of the library." I totally agree with Duncan that I've been in plenty situations where exploiting inner workings of some 3rd-party-code made my programming easier, only of course when nothing else helped. After all, that's what duck-typing is about. There is no official interface declaration, just an implicit protocol. And "private" methods or members are part of that protocol as well. Diez -- http://mail.python.org/mailman/listinfo/python-list
