It is a surprisingly common error in 3rd party code to write something like this:

  try:
      eggs()
  except OSError, e:
      if e.errno == 17:
         ham()

This is wrong, because according to POSIX[0], “only […] symbolic names should be used in programs, since the actual value of the error number is unspecified.”

I was wondering why Python programmers keep writing such unportable code - e.g. I've never seen C code that would compare errno variable with a hardcoded integer. I came into conclution that the Python interpreter itself is (partially) to blame. Currently exception message generated from errno looks like this:

"[Errno 2] No such file or directory: '/punt'"

It would be better if the message was:

"[ENOENT] No such file or directory: '/punt'"

or, if the above is too hard to implement, even:

"No such file or directory: '/punt'"

And the lost footnote is:
[0] http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html#tag_02_03

I tend to agree that the errno is much less useful than the symbolic name.  The former is useful and will be available as an attribute, but the latter should be used in the str.  The change will probably break scads of doctests, but is probably worth it. :)

BTW, this came up in the PEP 3151 discussions, but I agree it's orthogonal to that PEP.

It doesn't bother me that Python programmers can write unportable code, what with consenting adults and all that. Further the implementation of PEP 3151 in 3.3 allows specific exceptions to be caught, e.g. FileNotFoundError.  I can't see anybody allowing the exception number being changed to the symbolic string or even omitted completely, so I'd recommend this is closed unless there's an extremely good reason not to do so.

The enum module that is likely to land in 3.4 will allow us to fix this.  We can discuss whether we want to just display the name, or both the name and the value.  Omitting it would indeed be bad, IMO.

This is a duplicate of bpo-2920 (which has a PR).