Quoth David Cournapeau <courn...@gmail.com>: > On Wed, Feb 4, 2009 at 2:36 AM, <thmpsn....@gmail.com> wrote: > > > > Pretty much, unless maybe the code documents what you're not supposed > > to access: > > But that's my point: that's just not true for many packages I have > used - some packages do follow the _ convention, some don't. For > example, to take an example I am somewhat familiar with: distutils > does not follow this at all. There is no documentation, and it is > almost impossible to know what's the API from implementation details, > the interface is leaking everywhere. Now, distutils is an "old" > package, but my experience at least showed me that this is relatively > common. > > There are some relatively well known packages which use a different > mechanism to clearly separate the intended API, without using the _ > convention, or more exactly in supplement of it.
This whole issue gets more complicated, I think, when you consider that what is "public" versus "private" in an API depends on the consumer. That is, you might have a group of modules that use a package-internal interface, while what the "outside world" is supposed to use is a more restricted API. The package-internal interface isn't _private_ in the sense of hiding things from anybody outside the class or its subclasses, but neither is it public. I won't be surprised to hear that languages with data hiding have some provision for this, but to my mind this is a "one, two, many" situation. That is, if you have one case, things are trivially simple. If you have two cases, you can differentiate them. But once you have three cases, you almost certainly have _more_ than three cases...in other words a problem in generalization. In my code I generally use _ for stuff that is class-private, and document the "outside" or "stable" API, and everything else is...whatever it needs to be. Perhaps the packages you are thinking of do something similar? --RDM -- http://mail.python.org/mailman/listinfo/python-list
