A pattern that keeps appearing in Python scripts, tutorials, and AI-generated code:<\/p>\n\n\n\n
def main():\n do_stuff()\n\nif __name__ == \"__main__\":\n main()\n<\/code><\/pre>\n\n\n\nThis is cargo-culted from C and Java<\/strong>, where a main()<\/code> function is a syntactic requirement. Python has no such rule. The above is functionally identical to:<\/p>\n\n\n\nif __name__ == \"__main__\":\n do_stuff()\n<\/code><\/pre>\n\n\n\nWhen\u00a0def main()<\/code>\u00a0actually makes sense<\/h3>\n\n\n\nThere is one legitimate use case: when you need a named entry point for Python packaging. If your pyproject.toml<\/code> defines a console script, it must reference a callable:<\/p>\n\n\n\n[project.scripts]\nmytool = \"mypackage.cli:main\"\n<\/code><\/pre>\n\n\n\nHere, def main()<\/code> earns its place. But this is a specific packaging concern \u2014 not a general best practice for every script you write.<\/p>\n\n\n\nWhy does this keep spreading?<\/h3>\n\n\n\n\n- Language habits:<\/strong>\u00a0Developers coming from C, Java, or Go carry the pattern into Python without questioning it.<\/li>\n\n\n\n
- LLM training data:<\/strong>\u00a0Models are trained on GitHub, which is full of this pattern, so they reproduce it automatically.<\/li>\n\n\n\n
- Misunderstood testability:<\/strong>\u00a0Some argue\u00a0
def main()<\/code>\u00a0makes code more testable. It doesn’t \u2014 if your logic is a monolith inside\u00a0main()<\/code>, it’s just as hard to test. Real testability comes from decomposing logic into focused, well-scoped functions.<\/li>\n\n\n\n- Cargo-culting tutorials:<\/strong>\u00a0Many “professional Python” guides include it as boilerplate, implying it’s idiomatic when it’s really just familiar.<\/li>\n<\/ul>\n\n\n\n
The Pythonic way<\/h3>\n\n\n\n
Write clean, decomposed functions. Use if __name__ == \"__main__\":<\/code> as a lightweight guard when you need it. That’s it.<\/p>\n\n\n\ndef process_data(data):\n ...\n\ndef save_results(results):\n ...\n\nif __name__ == \"__main__\":\n data = load()\n results = process_data(data)\n save_results(results)\n<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"A pattern that keeps appearing in Python scripts, tutorials, and AI-generated code: This is cargo-culted from C and Java, where a main() function is a syntactic requirement. Python has no such rule. The above is functionally identical to: When\u00a0def main()\u00a0actually makes sense There is one legitimate use case: when you need a named entry point for Python packaging. If your pyproject.toml defines a console script, it must reference a callable: Here, def main() earns its place. But this is a specific packaging concern \u2014 not a general…<\/p>\n