EnvironmentError and its subclass OSError add the value of errno in 
their error message.  This value is an integer but the specific value 
in an implementation detail and the C runtime recommends that 
programmers use the symbolic values instead.  Ex: one should use 
ENODATA instead of 61.  For the same reason, the Python interpreter 
should try to return the symbolic value or errno when possible.

The attached patch replaces errno in EnvironmentError.__str__() by its 
symbolic value when possible.

Overall, the patch looks good. I made a couple of fixes to make the
changes more robust.

I don't like the "import errno" while printing an exception...
It would be much more robust to store errorcode_dict in a static variable when python starts, and reuse it directly.

Agreed with Amaury. Module import could fail for various reasons (perhaps the same ones which led to the exception being raised!), or could deadlock if the import lock is being held. Also, having __str__ fail is usually very annoying for users (especially when it's the __str__ of an exception object).

If it's too hard to import errno at startup (because of bootstrapping), I would suggest using PyImport_ImportModuleNoBlock() instead, and silence errors (just print the numeric value of errno instead).

The patch already checks for failed import and falls back to printing  
numerical error code. However, I don't like the import either. I will  
think about the alternatives.

On May 28, 2010, at 8:27 AM, Antoine Pitrou <report@bugs.python.org>  
wrote:

>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> Agreed with Amaury. Module import could fail for various reasons  
> (perhaps the same ones which led to the exception being raised!), or  
> could deadlock if the import lock is being held. Also, having  
> __str__ fail is usually very annoying for users (especially when  
> it's the __str__ of an exception object).
>
> If it's too hard to import errno at startup (because of  
> bootstrapping), I would suggest using PyImport_ImportModuleNoBlock()  
> instead, and silence errors (just print the numeric value of errno  
> instead).
>
> ----------
> nosy: +pitrou
> versions: +Python 2.7, Python 3.1, Python 3.2
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2920>
> _______________________________________

This looks like something that can become part of PEP 3151.

Alexander is right that this should be considered as part of PEP 3151. Plus, changes to interpreter core are subject to the moratorium.

I am -1 on this. I would propose to create a superseding issue for implementing PEP 3151 and gathering dependant issues like this one. For a similar case see #2651.

PEP 3151 is already large enough and I don't want to add orthogonal changes to it. Furthermore, this change is only about the string representation of exceptions, and may be accepted for 3.2 even despite the moratorium.

This would still be a helpful improvement.

How about doing something similar for Windows when winerror is set? This is a common case since many os functions use the Windows API directly. Showing the symbolic error name will help to disambiguate exceptions, such as 

    FileNotFoundError (ENOENT) from:

        ERROR_FILE_NOT_FOUND
        ERROR_PATH_NOT_FOUND
        ERROR_FILENAME_EXCED_RANGE
        ERROR_BAD_PATHNAME
        ERROR_BAD_NET_NAME

    PermissionError (EACCES) from:

        ERROR_ACCESS_DENIED
        ERROR_SHARING_VIOLATION
        ERROR_LOCK_VIOLATION
        ERROR_NETWORK_ACCESS_DENIED
        ERROR_NOT_READY

It could also support additional error codes that are common or used internally, such as 

    ERROR_NOT_SUPPORTED
    ERROR_INVALID_NAME
    ERROR_MOD_NOT_FOUND
    ERROR_PRIVILEGE_NOT_HELD
    ERROR_CANT_RESOLVE_FILENAME
    ERROR_INVALID_REPARSE_DATA

Modules/_winapi.c:

    ERROR_NETNAME_DELETED
    ERROR_SEM_TIMEOUT
    ERROR_PIPE_BUSY
    ERROR_MORE_DATA
    ERROR_PIPE_CONNECTED
    ERROR_OPERATION_ABORTED
    ERROR_IO_PENDING
    ERROR_NO_SYSTEM_RESOURCES

Eryk, I'm not sure if something similar should be done for winerror. I think it's best to keep OSError_str() as simple as possible.