On 1/3/07, Thomas Wouters <thomas@python.org> wrote:
On 1/3/07, Guido van Rossum <guido@python.org> wrote:
On 1/3/07, Fred L. Drake, Jr. <fdrake@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