I think the people replying "explicit is better than implicit" are cargo culting, there are quite a few areas where Python was more than happy to add a bit of magic to make the language smoother to use. Besides `if __name__ == "__main__"` is hardly explicit if you're not familiar with the idiom (what's `__name__` exactly? Is it the file name? The process name? When is and isn't it set to `__main__`?).

I can think of a real problem with your approach however: in languages with a main function you usually can't have top level statements, only declarations. So in C if you write at the top level `while (1) { printf("Hi\n"); }` you get a compilation error. Now as compilers get smarter you can get constexprs in some languages but it's still very specific and entirely static. I guess you could also mention global constructors, but that generally comes with severe caveats and should be used very carefully.

Python on the other hand treats top level code like anything else. That's why the `if __name__ == "__main__"` pattern even works in the first place. Having a real-looking main function would send the wrong message IMO, because it would make people that it's the real entry point of the program which it's not, in Python the entry point is the first line of the file being executed, end of story.

I do think that Python would benefit having a clearer and more explicitly named helper function or variable for this use case however, something like "if this_file_is_executed()" or something like that. At least this way you'd know what the code is doing instead of this awkward anti-pattern being used these days. But of course by now it's probably not worth changing.

You only need the __main__ magic if you want a python file to be both a module and an executable script. This is a moderately advanced requirement. Beginners will tend to write scripts OR importable modules.

For debugging-in-REPL purposes it's often very convenient to have it both ways. I was taught as a beginner to treat it as idiomatic boilerplate for that reason--no harm in having it, and there when you need it. Then you can just import your script and ad hoc test your functions.

It's a good technique prior to introducing formal unit testing (and even then, supplemental ad hoc has advantages).

1) One of pythons design philosophies is "explicit is better than implicit".

2) This is not a hurdle to hello world.

    print("Hello World") 

is a complete program that does exactly what you want. Needing to wrap it in a function would be an additional hurdle.

For complex programs; that is a hurdle well worth jumping. But for simple scripts (python is a scripting language), or teaching purposes, it is not always needed.

Ad 1,

the current idiom uses dunder name, which is implicitly defined and looks special.

Making main special would be about the same level of a solution, yet more conventional

Dunder methods don’t “look” special, they are. Marking them as such has side-effects, and as soon as you see a dunder, you know you’re going “lower”.

If “main” has to be a special function, it must keep the dunder.

There's always `__main__.py` if you want something special.

I understand that what you have is a complete program but every new Pythonist is going to next read the documentation that says, “Having a main method is a really good idea” and go try to implement one. Sure, in 1% of cases, you’ll need the granular control over how main is called but since when do languages cater to the 1%?

Can't you just put code in `def main` and then have `main()` at the top-level if you don't need to worry about imports? It seems like you can probably get pretty far as a beginner before you need to worry about being able to both import and run the same file.

"Explicit is better than implicit" - PEP20

I wouldn't really say that it's a hurdle to greeting the world since you can just throw `print("Hello world")` at the top level.

"if name == “__main__” isn't magic, it serves a purpose. Sometimes name == “__main__” and sometimes it doesn't, and I want to specify different behavior in different cases.

Here, name is the name of the module. When the module is run by itself, this is the same as __main__, in which case I want the things specified by the if to run right away. This could be calling a main function, but a lot of times it's just is some tests or examples.

When the module is imported into another file, it's name is not the same as __main__. In this case I usually only want things in it to do stuff when they are called by the other file.

This doesn't have anything to do with a function literally called "main" though.

  if __name__ == "__main__":
    main()

Is a common idiom, but there's no connection between the two uses of the word main.