An exploration of why Python doesn't require a 'main' function

Not just because it's a lookup-by-name, but because globals are mutable everywhere, the interpreter has to assume that some other code has mutated the variable and has to re-fetch it in many cases.

There were some optimisations done in https://bugs.python.org/issue26219

Another benefit is re-usability. If you want your program to be callable as module or script from elsewhere without going through the tedious shell functions, "def main()" is the only way to go.

The same is true in Julia but for slightly different reasons. It's not just quicker variable lookup in Julia, but the fact that it will be JIT compiled. (Unlike CPython.)

This is true. A related post about discovering this, and some links to more info: https://news.ycombinator.com/item?id=18681745

Interestingly C# is introducing top-level programs now.

https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#top-...

I was reminded of BASIC (also with no main()) and replied similarly.

> especially in contrast with c and other languages that shoehorn you into defining a main function

i don't think that's a problem in languages with namespaces/modules -- a module might define a main(), it just wouldn't be used when it's imported. (unless you're in C, then you'd get a name clash)

Yeah, this was a funny thing for me to read because my first language was BASIC. When I encountered C, it was the surprising and unique one because it required all code to be inside a function body.

I suppose one of the advantages is that it makes separate compilation easier. Take several .c files, compile each one separately into a .o file, and what happens when you try to link them together? Where should you start executing?

Defining a function with a well-known name is a simple, easy solution to that.

Python doesn't need to solve this problem because you give it a file to start interpreting, and that file is the entry point. You either pass the file name as an argument or you use #! and that determines it.

Maybe it goes back to assembly language. If you look at a block of assembly or machine language code, it's not immediately obvious where the entry point is. You could guess that it's at address 0, but I don't think that's the case for all machines.

I think more important than having a main() function is to clearly delineate the entry point. And in Python, the entry point is the first line of the program.

Now I've noticed, at least within the Arduino environment, that it uses setup() and loop() as entry points, but code is executed before these functions are called, if for instance a global variable definition invokes a class constructor. I don't know if that's how "regular" C works, but it creates ambiguity as to what runs first.

There are other languages where it seems hard to guess where the actual entry point is located unless you know where to look.

The actual entrypoint to your program is defined in the elf header of whatever binary you execute (doesnt matter if it is C or not). Usually this entrypoint points to a function in libc, which after some setup calls the user's main function.

> ... why does C (and C derived languages) require a main function?

It doesn't actually. You just need an entrypoint defined for the loader. In practice most people don't want to go around libc, or fiddle with internals. This is much less true in embedded development, where main functions are sometimes missing.

Why doesn't C have global code? Probably because it would require abstracting further away from the generated assembly. If there is code that is not inside a function, how can it be called? Remember that the entry point to all programs is a function.

IIRC it is the C runtime that calls main(). In C all executable code must necessarily be inside functions, so inevitably there had to be one 'special' function that was called first.

> I think the better question is, why does C (and C derived languages) require a main function?

That's not the true question. The true question would be, "why does C (and C derived languages) require that all executable statements be within a function?" Requiring a main function is just a natural consequence of that.

At a guess, it makes the language simpler. The main function is just that -- a function. It uses tools the language already has to deal with arguments and exit codes.

Arguably it also keeps things like libraries simpler. For example, what would it mean for me to have top-level expressions in a dynamic shared library? Does it execute as soon as I dlopen() it? Does it create an implicit "init" function that I need to call?

Parts of the C runtime library need initialization and this initialization is done before main is called. Interpreters do this before you have a chance to run any user supplied code.

Nor do most Lisp variants, nor Pascal (anything in the PROGRAM block is run as main). I guess to make the parser implementation simpler?

To complicate things, C++ has a main() function but also runs constructors and destructors of global objects before and after main().

C needs a main function because all matters of initialization and module dependencies are left to the programmer.

C has no concept of a module A depending on a module B.

If C had top-level executable statements, there would be no defined order to them. Proof: C++ has a way of executing top-level code via file-scope definitions of class objects that have constructors and destructors. The order of these is not defined by the language; it depends on how the object files are linked and such.

Niklaus Wirth's Modula-2 language has syntax for this. Every module has an anonymous block of code that is executed at program initialization time. Modules declare dependencies on each other, which cannot be cyclic. If A uses B, then B's initialization code runs before that of A.

There is a single root module on which nothing else depends, and that module's initialization code runs last. In that initialization code, you can do the application startup; it serves as main.

I think some other languages in this broad family are that way also, like Ada.

Embedded systems written in free-standing dialects of C still choose to start with a function, though not necessarily main. For instance, Linux starts with a function called start_linux. That's not the first code in vmlinux that executes; there is assembly code above that, typically in a module called entry.S which will branch to start_linux.

This is very easy for embedded developers to deal with. There is no special run-time support for special global initialization blocks: it's just a function call named by a symbol that you can use as a branch target in the assembly code.

Even in Lisps, though there is no concept of a main function in dialects like Common Lisp, you have to specify a startup function when you save an executable image. This is because an image is not simply a collection of top-level forms that are to be evaluated, unlike a Lisp source file. It is not obvious what has to be executed when the image is restarted. Without the ability to specify a startup function, a possible choice might be this: that when the image is re-started, the save-image function (whatever it is called in the implementation) will appear to return a second time, perhaps with a value indicating "I'm now returning again due to the image being re-animated".

A compiled C program, at a very basic level, is analogous to a Lisp image.

A Lisp system loads some .fasl files, and then saves an image, specifying a startup function.

Similarly, in a C toolchain, the linker loads .o files and saves an image, recording in that image an entry point where to begin executing.

As a rule of thumb, if it's image-based, then it probably needs a startup function, unless there is an equivalent language feature for handling startup.

That applies to the booting of operating system images also. Consider:

MS-DOS has "autoexec".

Unixes run /sbin/init.

U-Boot has the bootcmd variable.

All of these are like a main startup function.

Absolutely. But on the other hand, it's still very useful that Python does work like this: it's nice to be able to directly do things at the top level (e.g. setting up "constants" with a little computation, conditionally importing modules or importing fallbacks, etc.). As the article says, it's also an extremely clean way of defining what gets run in what order during startup.

Pycharm also puts a handy play button on it too, which is literally the only reason I do it. (sheer laziness)

Coming from the other direction, random code that executes outside of functions is sloppy. It's harder to reason about and is a regular source of confusion and bugs.

Even with those languages, I find a main method is a good idea just for local-scoping of variables compared to the top level variables being 'global' by default.

PHP is actually my favorite here - since the standard way people use it (behind a webserver) means that old-style PHP had as many entry points as it had files which could get really confusing really quickly.

Modern PHP usage will generally concede the point now and pipe all requests through internal routing executed off of a single script exposed to the webserver/whatever.

My immediate reaction was “it does—but it’s in the interpreter so of course you don’t have to write it”.

Have you considered submitting the ballad of this unintentional malware to TheDailyWTF?

I don't see how these two are the same. No side effects at import time? Sure. But a program isn't meant to be imported, it's meant to be run, so there's no real expectation that a program should be importable without side effects.

No, this isn't so. And besides, the main function isn't even the first thing in your program to run. The standard library does some setting up first. For instance populating argc and argv.

You may enjoy reading this: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm... It explains a lot of how linux loads programs. It's a bit dated though: everything is 32 bit.

Yup - and even the most obfuscated language's main (PHP) has a single entry point - that entry point is just in apache[1] which figures out which of your bazillion PHP files to execute.

This article is bordering on nitpicking.

1. Or whatever other webserver - and actually you can directly invoke PHP via CLI, but I'm ignoring those for the most common way people tend to use it.

FORTRAN does not require one either, as you can see in this example:

http://www.99-bottles-of-beer.net/language-fortran-77-264.ht...

Yes the argument is trivial. But it illuminates design choices of each language which is interesting

Because languages that compile to a platform binary must obey rules of a system linker and a corresponding stdlib. Javascript is an active host for an entire js program, but C compiler is not. C source files turn into object files (.o/.obj and then .so/.dll for libraries) that have a particular format and may be linked with object files and libraries from other languages. A system linker then decides where the entry point is by looking in every object file for a _start symbol, which is usually implemented by clib, and it basically does:

  void _start(void) {
    extern int main(...);
    init_clib();
    exit(main(...));
  }

The exact procedure heavily depends on a build target. Also, C compiler cli tool (e.g. gcc) is usually a frontend for a compiler and a linker, among other tools, which may add to the confusion.

Object files are collections of symbols, either external, or defined in that file. Every non-extern symbol is a region (addr, len) with either data or code. There is no unnamed/main symbols by design. In theory, C could abstract that and allow code at column zero, but there is no rationale for that.

You've seen in Java how the main function has the `args` parameter as input, an approach which originally comes from C. In C code, main is actually not the first code that gets run during the program; a compiler-provided shim function called "start" sets up the environment, which includes creating the `args` array, and then calls main and passes args in as a parameter to main. The start function needs something to call, and args needs to come from somewhere; having an explicit main function with an args parameter isn't the only way to achieve this, but it's not a bad way by any means.

If javascript had one (or if Node had one), wouldn't top-level await be unnecessary?

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.

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.

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

The difference is simply that compiled languages distinguish between 'static' and 'dynamic'. Static things include types, constants, and static variables. In interpreted languages, these things are all dynamic constructs--defining a type is a runtime activity that actually involves executing some code that changes the internal state of the interpreter, and it can (and regularly does) happen intermixed between other computations.

Of course syntactically-speaking, compiled languages could allow users to interleave these static declarations amid instructions and make it the compiler's job to correctly sort out the static from the dynamic (and indeed many languages do this); however, this makes it trickier to write good parsers and it also makes it harder for humans to distinguish at-a-glance the static from the dynamic (and this distinction is important in programming).

> I suspect the answer is "we care about existing programmers more than people who are learning to program".

Arguably if you care about people who are learning to program, you don't just punt on teaching them the distinction between static and dynamic. I think it would be better stated, "we care more about the long-term interests of novice programmers than we do about their short term frustrations".

Different languages have different goals. It's fine if not all languages have simplicity and beginner-friendliness as a core concern.

What's the point of teachin newcomers something they need to give up later anyway though? (once their programs get big enough to be split over several files)