[Python-Dev] Renaming Include/object.h

[Collin Winter]

On 1/3/07, Neal Norwitz <nnorwitz at gmail.com> wrote:
> 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.

Was any course of action ever decided on for this issue, or was the
consensus that it would break too much code? If the latter, what about
making the change for Python 3000?

Collin Winter