On 2/25/07, Jeremy Hylton <jeremy at alum.mit.edu> wrote:
> On 1/3/07, "Martin v. Löwis" <martin at v.loewis.de> 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.
>
> I like the idea of renaming the header files, but I expect there is a
> lot more opportunity for breaking code that you estimate. I did a
> search on google.com/codesearch and found seven external packages that
> include Python.h and object.h (before I gave up).
So rather than a simple rename, we should probably rename, change all
references in the core to use the new name, and make a simple object.h
that only does:
#include "new_object.h"
> I assume we expect people won't include it, because it is also
> included in object.h. But they do it. Is there documentation that
> says you shouldn't import it?
I thought somewhere (embedding/extending doc?) it mentions that only
Python.h should be included, but if we have a naming
convention/directory structure, this becomes more obvious.
Doc/ext/extending.tex:
To support extensions, the Python API (Application Programmers
Interface) defines a set of functions, macros and variables that
provide access to most aspects of the Python run-time system. The
Python API is incorporated in a C source file by including the header
\code{"Python.h"}.
(But it may not say nothing else should be included.)
n
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4