When we completely switch Windows builds over to VC14, we're going to encounter some new assert dialogs from the CRT. These won't appear in release builds, but because the buildbots run tests against debug builds they will get in the way. A number of tests attempt operations on bad file descriptors, which will assert and terminate in MSVCRT (I have a fix for the termination coming, but the assertions will still appear).

Currently regrtest has a "-n" flag to disable assertions using an MSVCRT function. This works fine with the exception of subprocesses, that do not inherit the setting.

The setting is process-wide, so we can't just turn assertions off around the code that may assert. We also can't turn them off completely without affecting users (e.g. #3545 and #4804).

#4804 has the discussion leading to the current state where _PyVerify_fd and the -n flag above exist. The _PyVerify_fd function could break with future CRT changes (bearing in mind that Python 3.5 and later will automatically use the latest installed CRT), for which there is an official workaround coming soon, except it won't suppress the assertion dialog for debug builds.

I'd like to propose three options:

1. Make faulthandler.enable() also disable assertions in debug builds. (Assertions are for debugging, and enabling faulthandler - at least on Windows - seems to suggest that you want to override the debugger. We also already enable faulthandler for subprocesses in the test suite.)

2. Add an environment variable (PYTHONDISABLECRTASSERT?) and use it to disable assertions on startup. (It looks like at least some tests deliberately block envvars flowing through to subprocesses, so this may require test changes too.)

3. Add a new xoption and use it to disable assertions on startup.

Obviously we could do all three, though I kind of like the first one best.

Currently, I'm planning to make debug builds available alongside the release versions, as they are necessary for people to build debuggable versions of their extensions, so this is more important than it was in the past. But the problem is very much only on the buildbots/in the test suite and not on user's machines.

Thoughts?