ctypes defines a number of global symbols which aren't
namespace-prefixed, such as AllocFunctionCallback, FreeClosure, GetType,
IsSimpleSubType, MallocClosure, _AddTraceback, _CallProc,
alloc_format_string, conversion_mode_encoding, conversion_mode_errors,
get_error_object, getentry, module_methods (there are more, but the
other ones can be understood as being unambiguously prefixed, such as
with CData, CField, StgDict).

It would be good if these symbols either are changed to static, or get a
proper Py/_Py prefix.

Is it too late to fix this for Python 2.6 and Python 3.0?

Formally, I can't answer that question; you need to ask the RM.

Informally, I think only serious bugs can be fixed now; this bug is not
serious.

These are the symbols on the trunk (20090328). There are *very* general
names as well. How should this be resolved? Introduce macros for the old
names, or just rename these?

module_methods probably could be static.

  AllocFunctionCallback
  ArrayType_Type
  Array_Type
  CData_AtAddress
  CData_FromBaseObj
  CData_Type
  CData_get
  CData_set
  CField_FromDesc
  CField_Type
  CFuncPtrType_Type
  CFuncPtr_Type
  CThunk_Type
  CreateArrayType
  Extend_Error_Info
  FreeClosure
  GetType
  IsSimpleSubType
  MallocClosure
  PointerType_Type
  Pointer_Type
  _pagesize
  _pointer_type_cache
  alloc_format_string
  conversion_mode_encoding
  conversion_mode_errors
  get_error_object
  getentry
  init_callbacks_in_module
  module_methods
  new_CArgObject

Note there's a patch to get rid of FreeClosure:
http://cvs.fedoraproject.org/viewvc/devel/python/python-2.6-ctypes-noexecmem.patch?view=markup

I think simple renaming would be fine.

I do not see how module_methods could be made static; however, the
init_callbacks_in_module function should probably be removed completely.

Some other symbols could be made static because they are only used in a
single source file, Array_Type and CData_Type for example (there may be
more).

For MallocClosure/FreeClosure and the fedoraproject patch: Where does
ffi_closure_alloc and ffi_closure_free come from?

Here is a quite large patch (300 lines) against svn trunk that renames a
lot of symbols.
The list of symbols, listed by 'nm -g --defined-only _ctypes.so' is as
follows:

theller@tubu32:~/devel/trunk$ find . -name _ctypes.so | xargs nm -g
--defined-only
00011d07 T My_PyUnicode_AsWideChar
00011c6e T My_PyUnicode_FromWideChar
000136e2 T PyCArgObject_new
000236e0 D PyCArg_Type
000225a0 D PyCArrayType_Type
0000f86a T PyCArrayType_from_ctype
00022e40 D PyCArray_Type
0000b0b0 T PyCData_AtAddress
0000ae6f T PyCData_FromBaseObj
00022980 D PyCData_Type
0000b274 T PyCData_get
0000b82d T PyCData_set
000181bf T PyCField_FromDesc
00023ae0 D PyCField_Type
000227e0 D PyCFuncPtrType_Type
00022b60 D PyCFuncPtr_Type
00022440 D PyCPointerType_Type
00023220 D PyCPointer_Type
00022700 D PyCSimpleType_Type
00023920 D PyCStgDict_Type
0001627a T PyCStgDict_clone
00022200 D PyCStructType_Type
00017223 T PyCStructUnionType_update_stgdict
00023300 D PyCThunk_Type
00004fe4 T PyDict_GetItemProxy
00004dd1 T PyDict_SetItemProxy
00023e18 B PyExc_ArgError
0001660e T PyObject_stgdict
0001658c T PyType_stgdict
00023de8 A __bss_start
0001221b T _ctypes_add_traceback
00012f75 T _ctypes_alloc_callback
0001d737 T _ctypes_alloc_closure
0000506e T _ctypes_alloc_format_string
0001469d T _ctypes_callproc
00023dec B _ctypes_conversion_encoding
00023df0 B _ctypes_conversion_errors
000143f5 T _ctypes_extend_error
0001d70a T _ctypes_free_closure
00013318 T _ctypes_get_errobj
00013f41 T _ctypes_get_ffi_type
0001d5be T _ctypes_get_fielddesc
000237c0 D _ctypes_module_methods
00023e14 B _ctypes_ptrtype_cache
0000b204 T _ctypes_simple_instance
00023de8 A _edata
00023e1c A _end
0001e264 T _fini
00003f48 T _init
0001dbda T ffi_call
0001e080 T ffi_call_SYSV
0001d9fc T ffi_prep_args
0001d883 T ffi_prep_cif
0001db62 T ffi_prep_cif_machdep
0001d9ba T ffi_prep_closure
0001de09 T ffi_prep_closure_loc
0001dea0 T ffi_prep_raw_closure_loc
0001df8b T ffi_raw_call
00023a64 D ffi_type_double
00023a58 D ffi_type_float
00023a70 D ffi_type_longdouble
00023a7c D ffi_type_pointer
00023a1c D ffi_type_sint16
00023a34 D ffi_type_sint32
00023a4c D ffi_type_sint64
00023a04 D ffi_type_sint8
00023a10 D ffi_type_uint16
00023a28 D ffi_type_uint32
00023a40 D ffi_type_uint64
000239f8 D ffi_type_uint8
000239ec D ffi_type_void
000115ec T init_ctypes
theller@tubu32:~/devel/trunk$

doko, loewis, what do you think?

Looks fine to me, except that I wouldn't call things "My*" (but I do
understand that this unrelated to this issue).

Correction: The patch has 3000 lines, not 300.

And I think that the 'My_Unicode_...' functions can be removed because
they are not used anywhere.  I have to check this.

Fixed in trunk (svn rev 71853).

I'll leave this open until it is ported to py3k.

BTW: The 'My_Unicode...' symbols are gone, too.

svn rev 71845, in py3k branch.