On 2009-01-07 10:33, Martin v. Löwis wrote:
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
>> However, they are still exported from the object files, 
> 
> Ah. Those are "global symbols", not "exported symbols"; "export"
> is a concept specific to Win32.

Not at all. .so share libs and .a libs on Unix provide exports
just as well.

>> so can cause
>> name clashes with other libraries you link with.
> 
> See, and in this specific case, they can't, because they are used
> only in a debug build. Furthermore, they all have names that are
> unlikely to collide. Even if they get a _Py_ prefix, there could
> still be a conflict.
>
>> Even production builds contain a few such symbols which require
>> the _Py or Py prefix (or need to be made static) - these are for
>> Python 2.6 and 2.7:
>>
>> * asdl_int_seq_new
>> * asdl_seq_new
> 
> No. They don't require the Py_ prefix, because they already
> have the asdl_ prefix.

Oh please. The convention is that *all* Python exported symbols
should start with either _Py or Py. That's an old convention which
was introduced with the Great Renaming in Python 1.4.

The above symbols violate this convention, as do any symbols
that get additionally exported in debug builds or any other
variant build of Python.

I consider it a bug that Python still exports symbols that
do not follow the convention. This makes it harder to tell
whether a symbol originated in Python or some other extension
or linked object/library file.