If I register an atexit handler, and then call os.execv, the handler is not invoked before my process changes over to the new program.  Shouldn't it be?  My program is ending, so my atexit handlers should be invoked.

This is based on this coverage.py bug:  https://bitbucket.org/ned/coveragepy/issue/43/coverage-measurement-fails-on-code  If the atexit handlers were invoked as part of os.execv, it would work properly.

That's a good question. Conceptually it makes sense, but I wonder if programs currently rely on os.execv not cleaning up anything: not only it doesn't call atexit handlers, but it also doesn't try to shutdown the interpreter. Which can be handy if you are using exec() in a fork() + exec() context (I think it is generally recommended to use os._exit(), not sys.exit() in a forked child).

FTR, with C's atexit(3), the handlers are not called either on exec().

The first reason for not calling atexit handlers upon exec() is that
it wouldn't be async-safe anymore, and could result in deadlocks.
Also, since atexit handlers are inherited upon fork(), running atexit
handlers upon exec() could result in such handlers being called
several times - something which should definitely be avoided.

Note that the atexit documentation states that handlers will only be
called in case of "normal interpreter termination".

So I'm -1 on the change, the chance of breaking existing applications
is way too high.

I agree with Charles-François, this is a too risky change.
However, we could definitely have a separate "atexec" handler, like the "atfork" handlers which are proposed in issue16500.