is python Object oriented??

[rdmurray at bitdance.com]

Quoth David Cournapeau <cournape at gmail.com>:
> On Wed, Feb 4, 2009 at 2:36 AM,  <thmpsn.m.k at 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