On Mon, Jan 5, 2009 at 2:58 PM, Marc-Andre Lemburg
<report@bugs.python.org> wrote:
..
> For completeness, all exported symbols in Python should have a _Py_
> prefix, even if they only get exported in certain debug builds.
>
I actually agree, but I felt that doing this as a part of this patch
would make it even less likely to be accepted.   There is another
change that needs to be done to the alloc counts - namely changing the
type from int to Py_ssize_t and %d to %zd in print formats.  I will
submit that as a separate issue.  (See issue4850.)

The only downside of having them is that a #ifdef __cplusplus
instruction strongly suggests that a file is intended to be valid C++,
which is currently not the case.

> Given that you can build Python as library on Unix and as DLL on
> Windows, there doesn't appear to be any need to actually be able
> to build Python itself using a C++ compiler. Simply using the
> header files and linking against those libraries should do the
> trick in most cases.

So what is your position on the proposed patch?  Is it worthwhile to
track down the remaining symbols that may be affected by removal of
extern "C" from .c files?  What is your opinion on the original patch
(c++-patch.diff) which restores C++ compilability but does not touch
these declarations?

I think using C++ as a lint variant from time to time is a good
exercise to catch some corner issues as I hope this patch
demonstrates.  I don't think this should be a requirement on every
submission, but once an effort is made to restore C++ compilability,
such changes should be applied unless there are valid concerns against
them.