[Python-Dev] Renaming Include/object.h (original) (raw)

Collin Winter collinw at gmail.com
Thu Mar 8 22:27:38 CET 2007

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

More information about the Python-Dev mailing list