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.