Python needs an actual default function
-
Python still has the
-ioption, and it still runs the same language as the files interface.The
-ioption is simply interactive mode. All commands still go through a compiler. -
Also, do y'all call main() in the if block or do you just put the code you want to run in the if block?
-
What is not hacky then in a language design?
Letting the developer decide what the code should do.
-
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/envwith parameterspythonand 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.soto 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:mainis a C thing.Is it possible to have a library that can be called and also executed like a program?
Absolutely.
ld.sois an example of that.. Actually, wait, I'm not so sure any more, I'm getting things mixed up withlibdl.so. In any caseld.sois 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
mainfunction, the symbol the kernel actually invokes is_start, the setup necessary to call a Cmainis done bylibc.so. Don't try to understand GNU's libc it's full of hystarical raisins I would suggest musl.wrote on last edited by [email protected]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.sois 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 0x1The 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 0x1It 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.
-
isn't that just normal usage? ..or, did I just whoosh and you were sarcastically saying that?
It is normal usage. Though personally I'd probably make another "main" function, to avoid declaring a bunch of global variables
-
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.sois 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 0x1The 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 0x1It 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.
wrote on last edited by [email protected]Your ld.so contains:Entry point address: 0x1d780EDIT: ...with which I meant, modulo brainfart: My
libc.so.6contains a proper entry address, while other libraries are pointing at0x0and coredump when executed.libc.sois a linker script, presumably because GNU compulsively overcomplicates everything....I guess that's enough for the kernel. It might be a linux-only thing, maybe even unintended and well linux doesn't break userspace.
Speaking of, I was playing it a bit fast and loose:
_startis merely the default symbol name for the entry label, I'm sure nasm and/or ld have ways to set it to something different. -
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.
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 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?"
aren't most of not all conventions hacky anyways?
-
procedural programming is more akin to that, but python has far to many oop concepts to be considered procedural imo
wrote on last edited by [email protected]Procedural and OOP aren't mutually exclusive terms. Most OOP programs are ultimately procedural in nature. Often, the only difference is that the first argument to the function is to the left the function name and separated by a dot.
-
What kind of psychopath would put the code in the if block.
you can, no one stopping you
-
I remember how weird this looked the first time I saw it and while I may now understand it, it still looks jank af
I still wonder why.
unless it's for something that you want to work as an importable module and a standalone tool, then why do you need that?
-
Procedural and OOP aren't mutually exclusive terms. Most OOP programs are ultimately procedural in nature. Often, the only difference is that the first argument to the function is to the left the function name and separated by a dot.
fair, I just think it's misleading to call python procedural, but it lines up with what the commenter above was describing and searching for the term for
-
Also, do y'all call main() in the if block or do you just put the code you want to run in the if block?
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.)
-
fair, I just think it's misleading to call python procedural, but it lines up with what the commenter above was describing and searching for the term for
I'd say the term "procedural" itself is an issue. Pretty much any language can be done that way if you choose. IIRC, the creator of Clojure wanted Java to work more that way, and he did it by having a single class full of functions. It's not a natural way to write Java, and that's why he invented Clojure.
-
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 callingmain()inside it) -
I still wonder why.
unless it's for something that you want to work as an importable module and a standalone tool, then why do you need that?
Oh that is a good point actually. It's been a while since I have done any serious Python, so I'm not sure why you couldn't just use convention instead of this conditional.
For my part, if a Python script is meant to be executed, then I'll give it a shebang, drop the .py, and simply mark it as executable in the filesystem.
️ -
I still wonder why.
unless it's for something that you want to work as an importable module and a standalone tool, then why do you need that?
wrote on last edited by [email protected]This is exactly why the conditional is used. It allows the script to function both as a standalone application and a library.
ETA: Probably would make sense to just treat it as default behavior in the interpreter and only require the conditional to overwrite in cases where
mainis not the main function and/or pre-processing is needed. -
Can you elaborate on this blood magic?
wrote on last edited by [email protected]It simply swaps some things around to make things more confusing, then goes into an infinite loop (whether or not you import or execute it standalone). it's no different than just including in the global scope:
while True: passI was kinda lazy with the fuckery, tbh. I could have gotten much more confusing, but don't have too much time today.
-
It is normal usage. Though personally I'd probably make another "main" function, to avoid declaring a bunch of global variables
Yeah. I like using
main()that way too. It's usually just a high-level function that handles globals relevant to running in standalone and calling other functions to do work. -
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!
