On Mon, Jan 5, 2009 at 11:43 AM, Marc-Andre Lemburg
<report@bugs.python.org> wrote:
..
>> GCC doesn't appear to do so, but there's no guarantee that other
>> C++ compilers won't touch these symbols:
>>
>> http://en.wikipedia.org/wiki/Name_mangling
>
> Issue #4846 is a good example of a situation where such name mangling
> causes problems even for non-function symbols.
>

You are right, I did not know that fact about MS compilers.   I am not
sure what this means to the isue of removing extern "C" from the .c
files, though.  Note that properly declared in header files global
symbols will not be affected, but only semi-private vars such as for
example allocs counters in Objects/object.c.

The allocs counters (tuple_zero_allocs, fast_tuple_allocs,
quick_int_allocs, quick_neg_int_allocs) present a case where it is
really hard to justify a change that is only motivated by C++
compilability.   Note that currently they are not getting extern "C"
at the point of definition (Objects/tupleobject.c and
Objects/intobject.c) but do at the point of declaration
(Objects/object.c).  Moving them to a header file would require
renaming with a _Py_ prefix.  Affected applications are really
esoteric: MS C++ compilation with -DCOUNT_ALLOCS.

I find it hard to get motivated to do a more thorough review of the
code searching for affected non-function symbols.  My original
motivation was just the curiosity as to why extern "C"  were added to
.c files.  I got my questions answered and I believe these
declarations serve no valid purpose, particularly inside the files
that no longer valid C++.

I see little to be gained in refining the patch further to support
non-g++ compilers.  It does not look like there is much interest in
C++ compilability to begin with.  Despite my posting to c++-sig
mailing list, no one has subscribed to this issue so far.   Maybe we
should ask on the python-list as well.