Python needs an actual default function

wait till you see

```

    
if __name__ = "__main__":

   main()
`

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.

yea I also couldnt get the formatting to work right, triple quotes kept turning things into accented letters, so I gave up.
and also := also known as the walrus operator is very fun and sometimes very convenient to use

I've always found needing to manually add a class instance parameter (i.e. self) to every object method really weird. And the constructors being named __init__. Not having multiple dispatch is kinda annoying too. Needing to use decorators for class methods, static methods, and abstract classes is also annoying. Now that I think about it, Python kinda sucks (even though it's the language I use the most, lol).
- 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.
  
  Guess I just prefer languages that do it this way:
  
  class AClass { var aProp = 0 fun aMethod() { aProp++ } }
  Though I suppose confusion and bugs can happen when you do something like:
  
  class AClass { var aProp = 0 fun aMethod(aProp: Int) { // `this.aProp` is needed to access the property } }

The if block is where my arg parser goes

I would put my code in a def main(), so that the local names don't escape into the module scope:

if __name__ == '__main__': def main(): print('/s') main()
(I didn't see this one yet here.)
- 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)
  
  I intended this an sarcastic example; I think it's worse than putting the main outside of the branch because of the extra indent-level. It does have an upside that the main() doesn't exist if you try import this as an module.

One thing I really dislike about Python is the double underscore thing, just really looks ugly to me and feels excessive. Just give me my flow control characters that aren't whitespace
- 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.
- Php says hello

Still better than having to create a new class just to implement
java

public static void main(String[] args) {}
Relevant Fireship video: https://youtu.be/m4-HM_sCvtQ
- Since Java 21, this has been shortened significantly. https://www.baeldung.com/java-21-unnamed-class-instance-main
  
  Impossible.
  
  Only took 27 years to make the Java "Hello, world!" kinda sane.
  
  Free standing functions in Java?! This can't be true.

Sometimes I have the misfortune of working with python code written by someone else and I wonder how a language like this became anything more than a scripting language
- 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.
  
  other people's Java
  I'm gonna have to disagree here, it's always a guessing game of how many layers of abstraction they've used to seemingly avoid writing any implementation code... Can't put the code related to "bicycles" in the Bicycle class, no, that obviously goes in WheeledDeviceServiceFactoryBeanImpl that's in the 'utils' package.
  
  How many lines are in a page?
  
  How do you feel about other peoples Go code?
- Sounds like a skill issue on your end
  
  Agreed. I program mainly in C so its easier for me to make sense of bad C code than bad python code which just makes me cry

What kind of psychopath would put the code in the if block.
- Looks at all the Python scripts in my bin folder that I wrote.
  
  Never heard of
  
  def main(): pass if __name__ == '__main__': main()
  ?
  
  custom bin folders are a realm no God dares to tread
- I work in an academic / research environment. Depending who wrote it, even seeing a __name__ == "__main__" is a bit of a rare thing...
  
  Academic code is absolutely horrific.
  Fortunately, it is possible to translate it for practical applications.
  
  Do you also have nothing but love for those 50+ cell Jupyter notebooks that don't use a single function and have everything in the global scope?
  
  python isn't the only language to do "execute everything imported from a particular file and all top level statements get run". both node and c# (but with restrictions on where top level statements can be) can do that type of thing, I'm sure there's more.
  python conventions are unique because they attempt to make their entrypoint also importable itself without side effects. almost no one needs to do that, and I imagine the convention leaked out from the few people that did since it doesn't hurt either.
  for instance in node this is the equivalent, even though I've never seen someone try before:
  
  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.}
- 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()
- 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.
- you can, no one stopping you

It really doesn't. It's a scripting language, functions are there but at it's core it runs a script. The issue is that it was so easy to start with that people started doing everything in it, even though it sucks for anything past complex scripts
It is the excel of databases.
- What's the difference between a "scripting" language and a "real" one?
  
  A scripting language controls an existing binary. A non-scripting language is used to create a new binary.
  
  Scripting languages are real. Generally people consider dynamic languages scripting languages but it's not that simple.
  
  It's a scripting language. What means that the computer runs it line by line, without needing to get the entire project first.
  
  I didn't say it wasn't real, it's just a scripting structure and not object oriented, so it doesn't make sense for it to start by looking for a "main" object
- 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...
  
  Readability? Me eyes bleed from a day of partially staring at python code, and there is a whole another week of that ahead. Tzinch (Edit: Tzeentch) help me

Did you know that main is usually a function?

Python people explaining fail to see the point: Yes we know dunders exist. We just want you to say: "Yeah, that is a bit hacky, isn't it?"
- Tbh reserving "main" is just a hacky if not more so than checking __name__ if you actually understand language design.
  
  Both are indeed equally terrible, even if it is for different reasons.
  The one true choice is of course letting the programmer choose the main function in compile/interpretation-time.
  I.e. python main.py --start "main" would start by calling the main function in main.py
  
  Reserving main is definitely more hacky. Try compiling multiple objects with main defined into a single binary - it won't go well. This can make a lot of testing libraries rather convoluted, since some want to write their own main while others want you to write it because require all kinds of macros or whatever.
  On the other hand, if __name__ == "__main__" very gracefully supports having multiple entrypoints in a single module as well as derivative libraries.
  
  Yeah, this is it.
  What's hacky about an introspective language providing environment to all of the executing code, so that the coder can make the decision about what to do?
  It would by hacky if Python decided "We'll arbitrarily take functions named "main" and execute them for you, even though we already started execution at the top of the file."
  For C, this is less so. The body of the file isn't being executed, it's being read and compiled. Without a function to act as a starting point, it doesn't get executed.
  
  What is not hacky then in a 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?

I call main() in the if
- I always use
  python
  
  if "__main__" == main: __main__()
  ..and earlier in the code:
  python
  
  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.
  
  Can you elaborate on this blood magic?

Does everyone call the function of the script main? I never use main(), just call the function what the program is supposed to do, this program calculates the IBNR? The function is called calculate_IBNR(), then at the end of the script if name = 'main': calculate_IBNR(test_params) to test de script, then is imported into a tkinter script to be converter to an exe with pyinstaller
- 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.

I use if__name__main__ often when working with AWS Lambda, but I also want to run it locally. Lambda wants to call a function with the params event and context. So I would do something like this:

def handler(event, context): things return { 'statusCode': 200, 'body': 'Hello from Lambda!' } if __name__ == '__main__': event = {} context = {} response = handler(event, context) print(response)
- Diabolical
  
  isn't that just normal usage? ..or, did I just whoosh and you were sarcastically saying that?

The if block is still in the global scope, so writing the code in it is a great way to find yourself scratching your head with a weird bug 30 minutes later.

lua

if debug.getinfo(1).what == "main" then -- ... end
Not that you'll ever use it. No, seriously.
Edit: actually, they are not quite equivalent. This code just checks whether we are outside any function, not necessarily in the main file (i.e. not in a module). I don't think there's an equivalent to Python's __name__ in stock Lua.

Could someone explain this please? I'm still a noob.
- 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.
  
  checks username
  So it's you they're always talking about
  
  Really helpful explanation, thanks.
- 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.
  
  thats why i name my modules main.py
  
  Really helpful explanation, thanks.
- 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.
  
  Python doesn't need the name main check to function at all. that's just a convenience feature that lets developers also include arbitrary entry points into modules that are part of a library and expected to be used as such. If you're writing a script, a file with a single line in it reading print("hello world") will work fine when run: python thescript.py

"pythonic"

Nothing prevents you from putting a call to “main()” in the global scope
- 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).
  
  Dumb person question: if it's good practice to do this so things don't go sideways, shouldn't it be a built-in feature/utility/function/whatever?
- Just cross your fingers nobody attempts to import it...
  
  Due to the oneness of all things, I refuse to distinguish between library code and executable code. One and Zero are arbitrary limitations.

Alternative: put entry point code in file __main__.py & run the containing package (eg, some_package) as a top-level expression (eg, python -m some_package).
- TIL. Thanks for that!

Call the function from the if block.
Now your tests can more easily call it.
I think at my last job we did argument parsing in the if block, and passed stuff into the main function.

Depends on how lazy I am at the moment.

main.py or did you not read the manual?

Can someone explain to me how to compile a C library with "main" and a program with main? How does executing a program actually work? It has an executable flag, but what actually happens in the OS when it encounters a file with an executable file? How does it know to execute "main"? Is it possible to have a library that can be called and also executed like a program?
Anti Commercial-AI license
- 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.
  
  EDIT: It does work. My (GNU) libc spits out version info when executed as an executable.
  How does that work? There must be something above ld.so, maybe the OS? Because looking at the ELF header, ld.so is a shared library "Type: DYN (Shared object file)"
  
  $ 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
  The program headers don't have interpreter information either. Compare that to ls "Type: EXEC (Executable file)".
  
  $ 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
  It feels like somewhere in the flow there is the same thing that's happening in python just more hidden. Python seems to expose it because a file can be a library and an executable at the same time.
  Anti Commercial-AI license
- 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
- 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().
- 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.

Shouldn't the third panel just be empty?
- It’s fine like this

Its called runpy.run_script