Logged In: YES 
user_id=14198

The problem only occurs when the 2 DLLs must cooperate WRT 
CRT resources.  Eg, if a "FILE *" was ever passed and used 
across the expat->Python boundary, or a memory block 
allocated in one to be freed in the other, then we would be 
in the same situation.  This probably doesn't happen for 
expat and Tk.  For Python and its extension modules (and 
even embedders), it may.

IIRC, the problem with memory blocks was solved some time 
ago, leaving FILE* the only real problem.  File objects are 
used in only 1 or 2 cases, and these could be solved by 
moving to "PyFile_Write()" style APIs.

So, I guess I could agree a good solution is to ensure that 
Python C API does not require CRT resource sharing, and 
that Py_DEBUG is defined independently of _DEBUG or DEBUG.  
Individual extensions would be responsible for setting 
Py_DEBUG via their makefiles in debug builds.  This should 
be stable.

This would blur the _d convention.  I quite like it, but I 
agree it is a PITA for many people.  We could try giving 
pythonxx_d.dll the ability to load non _d versions, in the 
hope that the extensions have been "fixed" so they don't 
directly share the CRT.

Tim - never quite understood your feelings on _d - what are 
your thoughts?