Add a dedicated subclass for recursion errors

[elazarg]

BPO	19235
Nosy	@birkenfeld, @rhettinger, @pitrou, @larryhastings, @bitdancer, @berkerpeksag, @1st1, @elazarg, @ilevkivskyi
Files	recursion_error.patch

^{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 = 'https://github.com/1st1'
closed_at = <Date 2015-07-03.05:18:28.884>
created_at = <Date 2013-10-12.16:41:47.874>
labels = ['interpreter-core', 'type-feature']
title = 'Add a dedicated subclass for recursion errors'
updated_at = <Date 2015-07-03.05:18:28.882>
user = 'https://github.com/elazarg'

bugs.python.org fields:

activity = <Date 2015-07-03.05:18:28.882>
actor = 'yselivanov'
assignee = 'yselivanov'
closed = True
closed_date = <Date 2015-07-03.05:18:28.884>
closer = 'yselivanov'
components = ['Interpreter Core']
creation = <Date 2013-10-12.16:41:47.874>
creator = 'elazar'
dependencies = []
files = ['32091']
hgrepos = []
issue_num = 19235
keywords = ['patch']
message_count = 16.0
messages = ['199595', '199607', '199608', '199728', '200585', '200700', '212808', '212809', '244501', '245474', '245478', '245479', '245480', '246114', '246134', '246135']
nosy_count = 10.0
nosy_names = ['georg.brandl', 'rhettinger', 'pitrou', 'larry', 'r.david.murray', 'python-dev', 'berker.peksag', 'yselivanov', 'elazar', 'levkivskyi']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue19235'
versions = ['Python 3.5', 'Python 3.6']

[elazarg]

There's no dedicated StackOverflowErrorException, So there is no way to accurately distinguish a recursion overflow from a general RuntimeError.

One cannot use the exception message, since the docs explicitly says that "Exception messages are not part of the Python API", and checking for

len(traceback.extract_tb(trace)) >= sys.getrecursionlimit()-1

is ugly, and (AFAIK) not guaranteed to be correct.

Use case: I've found this while trying to create a cycle detector that will compress the traceback of such errors.

See discussion in python-ideas:
https://mail.python.org/pipermail/python-ideas/2013-September/023190.html

An cycle-detection implementation:
http://code.activestate.com/recipes/578660-concise-output-for-maximum-recursion-depth-exceede/

[pitrou]

This sounds like a reasonable feature request to me.

[birkenfeld]

I agree.

[birkenfeld]

Attached is a patch, please review. Introduces a RecursionError that subclasses RuntimeError for compatibility.

Note: I also tested this with RecursionError not subclassing RuntimeError, to make sure that except clauses in the test suite are sufficiently narrowed to RecursionError.

[elazarg]

Looks good to me.

Is it possible to add it to 2.7? I think it won't break any PEP-8-following code (e.g. not testing for type equality/identity)

[rhettinger]

+1

[elazarg]

Is it going to be committed?

[bitdancer]

It's an enhancement, so it can only go in 3.5, and that will happen some time after the release of 3.4.

[elazarg]

Ok

[elazarg]

So what holds it back now?

[1st1]

+1.

This, unfortunately, can't go in 3.5 (too late), but I can commit this in 3.6.