Python needs an actual default function

Looks at all the Python scripts in my bin folder that I wrote.

def main():
    pass

if __name__ == '__main__':
    main()

I work in an academic / research environment. Depending who wrote it, even seeing a __name__ == "__main__" is a bit of a rare thing...

if (path.resolve(url.fileURLToPath(import.meta.url)).includes(path.resolve(process.argv[1])))
{
  // main things
}

Why would you waste a function call on something so completely redundant?

For real though, arg parsing goes in the if, then gets dispatched to whatever function call is needed to run the proper script.

I definitely do for quick scripts, but I try to break this habit. The biggest advantage of def main() is that variables are local and not accessible to other functions defined in the same script, which can sometimes help catch bugs or typos.

If the file is just a class I usually put example usage with some default arguments in that block by itself. There is no reason for a "main" function. It's a nice obvious block that doesn't run when someone imports the class but if they're looking at the class there is a really obvious place to see the class usage. No confusion about what "main()" is meant to do.

if __name__ == '__main__':
    # MyClass example Usage
    my_object = MyClass()
    my_object.my_method()

you can, no one stopping you

I always use

if "__main__" == main:
    __main__()

..and earlier in the code:

def __main__():
    while True:
        pass
main = "__main__"

This helps to prevent people from arbitrarily running my code as a library or executable when I don't went them to.

while True:
    pass

I feel that Python is a bit of a 'Microsoft Word' of languages. Your own scripts are obviously completely fine, using a sensible and pragmatic selection of the language features in a robust fashion, but everyone else's are absurd collections of hacks that fall to pieces at the first modification.

To an extent, 'other people's C++ / Bash scripts' have the same problem. I'm usually okay with 'other people's Java', which to me is one of the big selling points of the language - the slight wordiness and lack of 'really stupid shit' makes collaboration easier.

Now, a Python script that's more than about two pages long? That makes me question its utility. The 'duck typing' everywhere makes any code that you can't 'keep in your head' very difficult to reason about.

Sounds like a skill issue on your end

Php says hello

I'm at peace with balanced underscores (like "dunder name equals dunder main") and the internal ones for snake case, but in the unbalanced ones (prefixing unders and dunders for pseudo-private) still bug me. But at least, conventionally, it's visually the same idea as Hungarian notation.

Interesting observation. Can you give an example where this is relevant?

Since Java 21, this has been shortened significantly. https://www.baeldung.com/java-21-unnamed-class-instance-main

Tbh reserving "main" is just a hacky if not more so than checking __name__ if you actually understand language design.

Is it? I really don't think so. What can you propose that's better? I think if __name__ == __main__ works perfectly fine and can't really think of anything that would be better.

And you don't have to use it either if you don't want to anyway, so no, I don't think it's that much of a hack. Especially when the comic compares C as an example, which makes no sense to me whatsoever.

aren't most of not all conventions hacky anyways?

What's the difference between a "scripting" language and a "real" one?

echo "hello"
sleep 5
echo "goodbye"

Excel recently added the ability to run python code lol

compared with other languages at the time, the ease of access and readability makes it worth it. plus, the heavy duty stuff is usually handled by more optimised code line numpy or sklearn...

Python has a bunch of magic variables, like __name__. This one contains the name of the module you're currently in (usually based on the file name), so if your file is called foo.py, it will have the value foo.

But that's only if your module is being imported by another module. If it's executed directly (e.g. python foo.py), it will instead have a __name__ of __main__. This is often used to add a standalone CLI section to modules - e.g. the module usually only defines functions that can be imported, but when executed it runs an example of those functions.

Basically, when you compile a program written in Rust or C/C++ (the first and second panels respectively), the compiler needs to know what's supposed to be executed first when the program is run directly (i.e. when you click on the executable), which in these languages, is denoted by a special function called main(). Executable files can also contain functions and data structures that can be called by other programs, and when they are, you wouldn't want to run an entire complex and resource intensive program if another program only needs to call a single function from it. In that case, the other program will call the function it wants but not main, so only that function executes and not the entire program.

However, Python is a scripting language that's interpreted. So every Python source file is executable provided you have the Python runtime. Python also doesn't have native support for main functions in the same way Rust and C/C++ does, and it will execute every line of code as it reads the source file. This is why a single line Python file that just calls print is valid, it doesn't need to be wrapped in a main function to execute. However, what if your Python file is both meant to be executed directly and provides functions that other Python files can call? If you just put the main routine in the root of the file, it would be executed every time another program tries to import the file in order to call functions from it, since the import causes the file to be interpreted and executed in its entirety. You can still just have a main function in your file, but since Python doesn't natively support it, your main function won't do anything if you run the file directly because as far as Python is concerned, there is no executable code at the root of the file and you haven't called any functions.

The workaround is to have a single if statement at the root of the file that looks like this:

if __name__ == '__main__':
    main()

It checks a special variable called __name__. If the Python file is directly executed, __name__ will have the value of the string '__main__', which satisfies the if statement so main() is called. If another Python file imports it, the value of __name__ will be the name of that file, so main() isn't called. It's clunky and not that efficient, but, 1, it works, and 2, if you cared about efficiency, you wouldn't be writing it in Python.

All code needs to have an entry point.

For Python and some other languages, this is the start of the file.

For other languages, this is a special function name reserved for this purpose - generally, "main".

In the first kind of language, the thought process is basically: I have the flow of execution, starting at the top of the file. If I want to make a library, I should build the things I want to build, then get out of the way.

In the other kind of language, the thought process is basically: I am building a library. If I want to make an executable, I should create an entry point they the execution starts at.

The debate is honestly pretty dumb.

I'm a little new to Python standards. Is this better or worse than putting the def main(): outside the if statement (but calling main() inside it)

Diabolical

The point of the name==main logic is that it checks if that is the file that was invoked (like running python filename.py). If you just put a main() in the global scope it will be called either when the file is invoked or loaded (which can cause unintended consequences).

Just cross your fingers nobody attempts to import it...

All of mine are called do_thing() because after a few days of working on it, the scope creep always means the original name was wrong anyway.

TIL. Thanks for that!

Luckily Python is one step ahead:

Python 3.13.3 (main, Apr 22 2025, 00:00:00) [GCC 15.0.1 20250418 (Red Hat 15.0.1-0)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> if __name__ = "__main__":
... 
...    main()
...    
    File "<python-input-0>", line 1
    if __name__ = "__main__":
        ^^^^^^^^^^^^^^^^^^^^^
SyntaxError: invalid syntax. Maybe you meant '==' or ':=' instead of '='?

Also TIL that := is a thing in Python.

Nah self is quite important. The main part of a method is to access the state of the object. self is just the interface to it.

class AClass {
  var aProp = 0

  fun aMethod() {
    aProp++
  }
}

class AClass {
  var aProp = 0

  fun aMethod(aProp: Int) {
    // `this.aProp` is needed to access the property
  }
}

How does executing a program actually work?

Way too long an answer for a lemmy post

It has an executable flag, but what actually happens in the OS when it encounters a file with an executable file?

Depends on OS. Linux will look at the first bytes of the file, either see (ASCII) #! (called a shebang) or ELF magic, then call the appropriate interpreter with the executable as an argument. When executing e.g. python, it's going to call /usr/bin/env with parameters python and the file name because the shebang was #!/usr/bin/env python.

How does it know to execute “main”?

Compiled C programs are ELF so it will go through the ELF header, figure out which ld.so to use, then start that so that it will find all the libraries, resolve all dynamic symbols, then do some bookkeeping, and jump to _start. That is, it doesn't: main is a C thing.

Is it possible to have a library that can be called and also executed like a program?

Absolutely. ld.so is an example of that.. Actually, wait, I'm not so sure any more, I'm getting things mixed up with libdl.so. In any case ld.so is an executable with a file extension that makes it look like a library.

EDIT: It does work. My (GNU) libc spits out version info when executed as an executable.

If you want to start looking at the innards like that I would suggest starting here: Hello world in assembly. Note the absence of a main function, the symbol the kernel actually invokes is _start, the setup necessary to call a C main is done by libc.so. Don't try to understand GNU's libc it's full of hystarical raisins I would suggest musl.

$ readelf -hl ld.so
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - GNU
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x1d780
  Start of program headers:          64 (bytes into file)
  Start of section headers:          256264 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         11
  Size of section headers:           64 (bytes)
  Number of section headers:         23
  Section header string table index: 22

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000db8 0x0000000000000db8  R      0x1000
  LOAD           0x0000000000001000 0x0000000000001000 0x0000000000001000
                 0x0000000000029435 0x0000000000029435  R E    0x1000
  LOAD           0x000000000002b000 0x000000000002b000 0x000000000002b000
                 0x000000000000a8c0 0x000000000000a8c0  R      0x1000
  LOAD           0x00000000000362e0 0x00000000000362e0 0x00000000000362e0
                 0x0000000000002e24 0x0000000000003000  RW     0x1000
  DYNAMIC        0x0000000000037e80 0x0000000000037e80 0x0000000000037e80
                 0x0000000000000180 0x0000000000000180  RW     0x8
  NOTE           0x00000000000002a8 0x00000000000002a8 0x00000000000002a8
                 0x0000000000000040 0x0000000000000040  R      0x8
  NOTE           0x00000000000002e8 0x00000000000002e8 0x00000000000002e8
                 0x0000000000000024 0x0000000000000024  R      0x4
  GNU_PROPERTY   0x00000000000002a8 0x00000000000002a8 0x00000000000002a8
                 0x0000000000000040 0x0000000000000040  R      0x8
  GNU_EH_FRAME   0x0000000000031718 0x0000000000031718 0x0000000000031718
                 0x00000000000009b4 0x00000000000009b4  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x00000000000362e0 0x00000000000362e0 0x00000000000362e0
                 0x0000000000001d20 0x0000000000001d20  R      0x1

$ readelf -hl ls
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x40b6e0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          1473672 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         14
  Size of section headers:           64 (bytes)
  Number of section headers:         32
  Section header string table index: 31

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x0000000000000310 0x0000000000000310  R      0x8
  INTERP         0x00000000000003b4 0x00000000004003b4 0x00000000004003b4
                 0x0000000000000053 0x0000000000000053  R      0x1
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000007570 0x0000000000007570  R      0x1000
  LOAD           0x0000000000008000 0x0000000000408000 0x0000000000408000
                 0x00000000000decb1 0x00000000000decb1  R E    0x1000
  LOAD           0x00000000000e7000 0x00000000004e7000 0x00000000004e7000
                 0x00000000000553a0 0x00000000000553a0  R      0x1000
  LOAD           0x000000000013c9c8 0x000000000053d9c8 0x000000000053d9c8
                 0x000000000000d01c 0x0000000000024748  RW     0x1000
  DYNAMIC        0x0000000000148080 0x0000000000549080 0x0000000000549080
                 0x0000000000000250 0x0000000000000250  RW     0x8
  NOTE           0x0000000000000350 0x0000000000400350 0x0000000000400350
                 0x0000000000000040 0x0000000000000040  R      0x8
  NOTE           0x0000000000000390 0x0000000000400390 0x0000000000400390
                 0x0000000000000024 0x0000000000000024  R      0x4
  NOTE           0x000000000013c380 0x000000000053c380 0x000000000053c380
                 0x0000000000000020 0x0000000000000020  R      0x4
  GNU_PROPERTY   0x0000000000000350 0x0000000000400350 0x0000000000400350
                 0x0000000000000040 0x0000000000000040  R      0x8
  GNU_EH_FRAME   0x0000000000126318 0x0000000000526318 0x0000000000526318
                 0x0000000000002eb4 0x0000000000002eb4  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x000000000013c9c8 0x000000000053d9c8 0x000000000053d9c8
                 0x000000000000c638 0x000000000000c638  R      0x1

ld.so --help

LOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000
     0x0000000000028bb5 0x0000000000028bb5  R E    0x1000

You don't. In C everything gets referenced by a symbol during the link stage of compilation. Libraries ultimately get treated like your source code during compilation and all items land in a symbol table. Two items with the same name result in a link failure and compilation aborts. So a library and a program with main is no bueno.

When Linux loads an executable they basically look at the program's symbol table and search for "main" then start executing at that point

Windows behaves mostly the same way, as does MacOS. Most RTOS's have their own special way of doing things, bare metal you're at the mercy of your CPU vendor. The C standard specifies that "main" is the special symbol we all just happen to use

If you want to have a library that can also be a standalone executable, just put the main function in an extra file and don't compile that file when using the library as a library.
You could also use the preprocessor to do it similar to python but please don't.

Just use any build tool, and have two targets, one library and one executable:

LIB_SOURCES = tools.c, stuff.c, more.c
EXE_SOURCES = main.c, $LIB_SOURCES

Edit: added example

I haven't done much low level stuff, but I think the 'main' function is something the compiler uses to establish an entry point for the compiled binary. The name 'main' would not exist in the compiled binary at all, but the function itself would still exist. Executable formats aren't all the same, so they'll have different ways of determining where this entry point function is expected to be. You can 'run' a binary library file by invoking a function contained therein, which is how DLL files work.

There are a lot of other helpful replies in this thread, so I won't add much, but I did find this reference, which you could read if you have a lot of free time. But I particularly liked reading this summary:

• _start calls the libc __libc_start_main;
• __libc_start_main calls the executable __libc_csu_init (statically-linked part of the libc);
• __libc_csu_init calls the executable constructors (and other initialisatios);
• __libc_start_main calls the executable main();
• __libc_start_main calls the executable exit().

It’s fine like this