> One enhancement of this new API is that it now reports the name of the C function which causes the error. The initial bug report says "Fatal Python error: init_sys_streams: can't initialize sys standard 
streams": init_sys_streams() function raised the fatal error.

I think that's a welcome change, the main question is whether it's necessary to hard-crash the interpreter and dump the core, or if, in most cases, the error message + non-zero return code would be sufficient.

It's not clear to me how useful the traceback itself is, but of course I'm giving a toy example where the Python exception is sufficient to debug what's failing. I would think that *in general* if the interpreter is failing to initialize because of a problem in the Python stack, printing the Python traceback should be sufficient. If there's good reason to think otherwise, then I'm fine with closing this bug. Otherwise I'd say it would be nice to refactor in such a way that avoids the core dump when the problem is on the Python side (leaving in place the error message you added that shows where it failed on the C side).

> A workaround is the usage of -I option:

In this case I don't think we need a workaround, because the issue is really "should it be possible for a pure python crash to cause the interpreter to crash rather than exit with an error code?" Shadowing a standard library module from your PYTHONPATH is just the easiest way to manifest this. (Though probably more people should be using -I, so it's good to bring it up).


> A long term solution would to enable -I behavior by default: don't add the current directory to sys.path when using -c CMD.

If you've been following the recent issues with the PEP 517 rollout in setuptools, you'll see that I'm deeply sympathetic to this view (though in this case I'm not amazingly optimistic about its feasibility). Probably we shouldn't derail this issue too much with a discussion of our revolutionary views on the right default Python path, though.