[Python-Dev] New Python Initialization API
steve.dower at python.org
Tue Apr 9 16:20:46 EDT 2019
Thanks for the replies. Anything I don't comment on means that I agree
with you :)
On 05Apr2019 0900, Victor Stinner wrote:
> Honestly, I'm not sure that we really have to distinguish "user error" and
> "internal error". It's an old debate about calling abort()/DebugBreak() or
> not. It seems like most users are annoyed by getting a coredump on Unix
> when abort() is called.
I'm also annoyed by the crash reports on Windows when "encodings" cannot
be found (because occasionally there are enough of them that the Windows
team starts reviewing the issue, and I get pulled in to review and
resolve their bugs).
> Maybe we should just remove Py_INIT_USER_ERR(), always use Py_INIT_ERR(),
> and never call abort()/DebugBreak() in Py_ExitInitError().
Not calling abort() sounds fine to me. Embedders would likely prefer an
error code rather than a crash, but IIRC they'd have to call
Py_ExitInitError() to get the crash anyway, right?
> Or does anyone see a good reason to trigger a debugger on an
> initialization error?
Only before returning from the point where the error occurs. By the time
you've returned the error value all the useful context is gone.
> Note: I'm not talking about Py_FatalError() here, this one will not
Does this get called as part of initialization? If not, I'm fine with it
More information about the Python-Dev