[Python-Dev] New Python Initialization API

[Steve Dower]

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

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

Cheers,
Steve