[Python-Dev] Renaming Include/object.h

[Neal Norwitz]

On 1/3/07, Thomas Wouters <thomas at python.org> wrote:
>
>
> On 1/3/07, Guido van Rossum <guido at python.org> wrote:
> > On 1/3/07, Fred L. Drake, Jr. <fdrake at acm.org> wrote:
> > > On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote:
> > >  > In #1626545, Anton Tropashko requests that object.h should be
> > >  > renamed, because it causes conflicts with other software.
> > >  >
> > >  > I would like to comply with this requests for 2.6, assuming there
> > >  > shouldn't be many problems with existing software as object.h
> > >  > shouldn't be included directly, anyway.
> > >
> > > +1
> >
> > Maybe this should be done in a more systematic fashion? E.g. by giving
> > all "internal" header files a "py_" prefix?
>
> I was thinking the same, and I'm sure Neal Norwitz is/was too (he suggested
> this a few times in the past, at least outside of python-dev.)

Wow, I didn't realize I was that much of a broken record. :-)
I don't even remember talking to Thomas about it, only Guido.  I
definitely would like to see all private header files clearly denoted
by their name or directory.

I saw Jack's comment about Apple's naming scheme, but I'm ignoring
that for the moment.
I have bad memories from the Motif days of including everything with
one file.  I prefer to see includes with the directory.  This provides
a sort of namespace:

#include "python/foo.h"

Though, if the user only has to include a single Python.h like
currently, this wouldn't make as much sense.  I don't recall the same
problems in Python that existed when using Motif.

Here are some options (python/ can be omitted too):

  #include "python/public.h"
  #include "python/internal/foo.h"
  #include "python/private/foo.h"
  #include "python/_private.h"

I don't really like prefixing with py_ because from a user's
perspective I interpret py_ to be a public header that gives me a
namespace.  I prefer a directory that indicates its intent because it
can't be misunderstood.  IIRC Guido didn't want to introduce a new
directory.  In that case my second choice is to prefix the filename
with an underscore as a leading underscore often is interpreted as
private.

Going along with this change I would like to see all identifiers in
public header files prefixed with [_]Py.  And public header files
shouldn't be able to include private header files (by convention).  Or
we should have some other way of denoting which files must prefix all
their identifiers and which can use anything because they are only
used in Python code.

For example, right now node (struct _node) is exported in node.h in
2.4.  I think it moved in 2.5, but it's still exported IIRC.

n