In _PyCodecRegistry_Init() (in Python/codecs.c), it is attempted to import the encodings module (so that the default search function gets registered) and failures get ignored following the same reasoning: /* Ignore ImportErrors... this is done so that distributions can disable the encodings package. Note that other errors are not masked, e.g. SystemErrors raised to inform the user of an error in the Python configuration are still reported back to the user. */ However, it is unlikely for Python 3 to start up at all without an encodings package (we needs some codecs to initialize stdio). Also, I'm not sure what the point would be. Distributions can simply distribute a dummy encodings module if they really want to disable the default encodings. Not silencing the error would probably make it easier to diagnose early import issues.
Those lines were whitespace reformed by Antoine in 61466/61463. They previously came from 28325 which fixed #663074 (2003). I do not see any discussion in that issue of making the import optional. I suspect there is no test of Python working with no encodings ;-) Just for fun, I commented out the import and error checks. There is an error message during the build about python_d.exe not working and python_d.exe crashes (ungracefully) on explicit startup, as you expected. I presume the patch is to delete the entire block added in 28325: if (PyErr_ExceptionMatches(PyExc_ImportError)) { /* Ignore ImportErrors... this is done so that distributions can disable the encodings package. Note that other errors are not masked, e.g. SystemErrors raised to inform the user of an error in the Python configuration are still reported back to the user. */ PyErr_Clear(); return 0; Only in 3.3 or further back? I can do it if you like.
Actually, that code is from bc861add5d71. But the error was also muted in the initial checkin in d0e06efb3165. In any case, the silencing should be removed, both in 3.2 and 3.3 IMO.
