[Python-Dev] New Python Initialization API (original) (raw)

Steve Dower 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 PyINITUSERERR(), always use PyINITERR(), and never call abort()/DebugBreak() in PyExitInitError().

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 PyFatalError() here, this one will not change.

Does this get called as part of initialization? If not, I'm fine with it not changing.

Cheers, Steve

More information about the Python-Dev mailing list