Patch to print symbolic value of errno in OSError.__str__()

[ygingras]

BPO	2920
Nosy	@amauryfa, @abalkin, @pitrou, @avassalotti, @ambv, @eryksun, @ZackerySpytz
PRs	gh-47169: Use the symbolic errno name in OSError error messages #14988
Files	python-26-sympolic-errno.diff: patch for symbolic errno symbolic-errno.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2008-05-19.20:14:34.567>
labels = ['interpreter-core', 'type-feature', '3.10']
title = 'Patch to print symbolic value of errno in OSError.__str__()'
updated_at = <Date 2021-03-22.19:43:06.919>
user = 'https://bugs.python.org/ygingras'

bugs.python.org fields:

activity = <Date 2021-03-22.19:43:06.919>
actor = 'eryksun'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2008-05-19.20:14:34.567>
creator = 'ygingras'
dependencies = []
files = ['10377', '10378']
hgrepos = []
issue_num = 2920
keywords = ['patch']
message_count = 11.0
messages = ['67074', '67077', '106651', '106654', '106655', '111206', '113333', '113334', '160879', '348820', '349135']
nosy_count = 8.0
nosy_names = ['amaury.forgeotdarc', 'belopolsky', 'pitrou', 'alexandre.vassalotti', 'ygingras', 'lukasz.langa', 'eryksun', 'ZackerySpytz']
pr_nums = ['14988']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue2920'
versions = ['Python 3.10']

Linked PRs

• gh-47169: Adding errno Symbolic Values to OSError.__str__() #150041

[ygingras]

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.

[avassalotti]

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

[amauryfa]

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.

[pitrou]

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).

[AlexanderBelopolsky]

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\>

---

[abalkin]

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

[ambv]

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 bpo-2651.

[pitrou]

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.

[pitrou]

This would still be a helpful improvement.