Why can't I just put my cleanup code at the end of my main function?

That's a fair question. In a simple script, you absolutely can. But as your projects grow, you'll find that your program doesn't always reach the final line of your main() function. Maybe you call sys.exit() halfway through because of a validation error, or an unhandled exception bubbles up and crashes the app. If your cleanup code—like closing a database connection or deleting a lock file—is just sitting at the bottom of the script, it never gets executed.

I've spent way too many hours debugging "stale lock files" because a script crashed and didn't run its final cleanup block. The atexit module solves this by registering "hooks." You're essentially telling Python, "I don't care how we get there, but before you shut down the interpreter, please run this specific function."

How do I actually set this up, and does the order of registration matter?

It's pretty straightforward. You import atexit and use the register function. You pass it the function name (without parentheses) and any arguments that function needs.

One thing that trips people up is the execution order. Python handles these hooks in LIFO order (Last-In, First-Out). The last function you register is the first one to run. Think of it like a stack of plates; you put the last one on top, so you take it off first.

import atexit
import os

def cleanup_temp_files():
    print("Cleaning up temporary files...")
    if os.path.exists("temp_work_file.txt"):
        os.remove("temp_work_file.txt")

def close_network_socket():
    print("Closing network sockets...")

# Registering the hooks
atexit.register(cleanup_temp_files)
atexit.register(close_network_socket)

# If the program ends here, close_network_socket runs FIRST, 
# then cleanup_temp_files runs SECOND.

Does this guarantee my cleanup will always run, even during a crash?

I have to be honest with you: no, it doesn't guarantee everything. atexit is great for "graceful" exits. This includes when your script finishes naturally, when you call sys.exit(), or even when an unhandled exception occurs.

However, there are a few scenarios where atexit is completely bypassed. If the Python interpreter itself crashes (a segfault), or if you kill the process forcefully using kill -9 (SIGKILL) on Linux or ending the task via Task Manager on Windows, the hooks won't run. Also, calling os._exit() explicitly skips all cleanup hooks. If you're building something where data integrity is life-or-death even during a power failure, you'll need more robust solutions like journaling or write-ahead logging, but for 95% of application cleanup, atexit is exactly what you need.

📋 Practical Task

Exercise: Building a Process Lock-File Manager

In many production environments, you want to prevent two instances of the same script from running simultaneously. A common way to do this is by creating a "lock file" when the script starts and deleting it when the script ends.

Your Task: Write a script that does the following:

• Creates a file named app.lock at the start of the program.
• Defines a cleanup function that deletes app.lock and prints "Lock file removed. System clean."
• Registers this cleanup function using the atexit module.
• To test it, add a sys.exit() call in the middle of your code.

Verify that even though you called sys.exit() before the end of the script, the app.lock file is successfully deleted from your directory.