define built-in exceptions in Python code

[brettcannon]

BPO	18170
Nosy	@brettcannon, @tiran, @benjaminp, @ezio-melotti

^{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 2013-06-08.23:54:59.344>
labels = ['interpreter-core', 'type-feature', '3.7']
title = 'define built-in exceptions in Python code'
updated_at = <Date 2016-09-25.13:21:37.627>
user = 'https://github.com/brettcannon'

bugs.python.org fields:

activity = <Date 2016-09-25.13:21:37.627>
actor = 'christian.heimes'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2013-06-08.23:54:59.344>
creator = 'brett.cannon'
dependencies = []
files = []
hgrepos = []
issue_num = 18170
keywords = []
message_count = 3.0
messages = ['190837', '190848', '190880']
nosy_count = 5.0
nosy_names = ['brett.cannon', 'christian.heimes', 'benjamin.peterson', 'ezio.melotti', 'cvrebert']
pr_nums = []
priority = 'low'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue18170'
versions = ['Python 3.7']

[brettcannon]

This quite possibly won't work because of performance, but I have been wondering how feasible it would be to define as many core exception types as possible in pure Python code and then freeze the module for loading. It would have the benefit of making maintenance easier (e.g. all of the PEP-3151 exceptions would have been simpler to add). It also would make it easier on other VMs by minimizing the number of exceptions that have to be written in their implementation language.

Implementation-wise, it's probably easiest to start with leaf exceptions in the inheritance hierarchy and then slowly port more and more. Any exceptions ported to pure Python would have their PyExc_* variable set to their parent so that the variable is initialized to some exception before any Python code is touched. The real trick will come down to dealing with situations where some specific C API has been exposed (e.g. UnicodeError).

Even if this experiment turns out to be feasible and reasonable in terms of simplifying C code, the other question is performance. If this costs more than a couple percent of overall performance (and quite possibly not even at that expense) this would not be worth it.

[benjaminp]

I suppose you'd better hope that there are no errors loading said frozen module. :)

[brettcannon]

Yeah, that's the tricky bit. =) That's why I was thinking of starting with the leaf exceptions and then just slowly working down the hierarchy until I hit exceptions that just had to exist in C code (e.g. BaseException, Exception, and maybe SyntaxError). The rest could be made fake with Exception to start and then replace after the module was loaded.

[iritkatriel]

This issue has been idle for over a decade. Do we still want to discuss this or shall we close it?

[picnixz]

Since this issue has been opened for over a decade, I'll take the liberty of closing it. Let's create a DPO thread if we want to ressurect this issue.