We are using Windows XP SP2, Visual Studio 2005 & Python 2.5.2.
In Objects/exceptions.c the following code turns off all assertions.

#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__)
    /* Set CRT argument error handler */
    prevCrtHandler = _set_invalid_parameter_handler
(InvalidParameterHandler);
    /* turn off assertions in debug mode */
    prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0);
#endif

As far as I understand, this is to make sure that no assertion dialogs 
pop up during the internal Python tests. For ordinary users, this is 
not an issue.

However, we are using the Python DLL in our product and when developing 
we always use the debug version of the Python DLL (as recommended). 
When we do Py_Initialize() all assertions are turned off, even our 
assertions, and this is not what we want. The current workaround is as 
follows (this is in our code):

   prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,_CRTDBG_REPORT_MODE);
   Py_Initialize();
   prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,prevCrtReportMode);

I am not certain if this is a bug or a feature and I really do not have 
a suggested solution since I do not know the real reasons for turning 
off assertions. Perhaps there already is a way to avoid this problem 
that I have not found?

All comments are appreciated.

As you must be building your own Python DLL, anyway, can't you just
simply remove that code if you don't want it?

Yes, we could do that. However, my concerns are:

1) We cannot be the only Python user that experience this issue? I 
would prefer one of these solutions (in this order):
 a) A parameter to Py_Initialize (structure) that controls its 
behaviour.
 b) A #define in pyconfig.h controls whether this should be done or not.
However, since I am not a Python developer myself, I cannot judge how 
much this would affect other things. I also realize that this involves 
some work and that it has very low priority.
2) We have to remember to do this change every time we upgrade to a 
newer version of Python. In earlier releases of Python where 
PyImport_AppendInittab did not exist, we had to do changes to the 
Python code every time we upgraded which was a hazzle. This is why I 
prefer the current workaround we are using where we reset the CRT 
report mode after Py_Initialize().
Your efforts are much appreciated and I realize that the current 
workaround we are using will probably be the final solution.

> 2) We have to remember to do this change every time we upgrade to a 
> newer version of Python. 

Every new MSVC release brings new problems, as far back as I remember.
Did you actually try to turn it off? Did it work? What if you do
'open("foo","bar")'? IIRC, turning this CRT checking code back on,
regular Python code can now crash Python, by triggering a CRT
assertion (these assertions are stupid, in the sense that they ban
behavior that is completely conforming to the ISO C standard, and
consider it incorrect). Turning off the assertions is the only
supported way to override the CRT behavior to crash the application.

I don't quite understand why this all affects your code. Are you
using ASSERT() by any chance? If so, why are you not using assert()
instead? That doesn't go through CrtDebugReport, AFAICT.

We started using Python 2.5.2 recently and a few developers have 
complained that they do not get any assertions anymore so yes, we do 
use _ASSERT() and _ASSERTE(), but after a brief look it seems as if we 
mainly use assert(). The developer using _ASSERT() cannot remember why 
this was necessary and the tests I have made today shows that we could 
probably move to assert() everywhere.

A more interesting aspect is that we have recently moved the the more 
secure CRT routines (strcpy_s etc) and tests have shown issues with 
these if we turn off assertions:

 int prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,0);
 char str[8];
 strcpy_s(str,"123456789");

With assertions turned on, I get an assertion dialog saying "Buffer is 
too small" which is what I expect and want. With assertions turned off 
(as in the example above), I get a dialog saying "Microsoft Visual 
Studio C Runtime Library has detected a fatal error in crt.exe.".

The stack is still useful and we can find the cause of the error so it 
is not a serious problem for us since we will continue to turn on 
assertions after Py_Initialize().

I have not yet seen any examples where the are erroneous assertions.

Anyway, you have made your point and I really do not want to take up 
anymore of your time. I respect your opinion and at least I have forced 
you to think about this. We have a workaround that works for us so I am 
OK with closing this issue.

Many thanks!

> I have not yet seen any examples where the are erroneous assertions.

Please take a look at the code in signalmodule.c. The MS CRT asserts
that the signal number is supported (i.e. among a fixed list of signal
numbers), even though C 99, 7.14.1.1p8 says that the library shall
return SIG_ERR, and set errno to a positive value, if the request cannot
be honored.