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?

  • _____@lemm.ee
    link
    fedilink
    English
    arrow-up
    0
    ·
    19 days ago

    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?”

    • namingthingsiseasy@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      19 days ago

      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.

    • Dr. Moose@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      19 days ago

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

      • bastion@feddit.nl
        link
        fedilink
        arrow-up
        0
        ·
        19 days ago

        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.

      • TheNamlessGuy@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        18 days ago

        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

      • namingthingsiseasy@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        19 days ago

        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.

          • bitfucker@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            19 days ago

            I don’t understand. What do you mean by deciding what the code should do in the context of language design? Can you give a concrete example? I am confused because the “main” function is required when you make an executable. Otherwise, a library will not contain any main function and we could compile it just fine no? (Shared library)

            • _stranger_@lemmy.world
              link
              fedilink
              arrow-up
              0
              ·
              19 days ago

              Python is an interpreted language that doesn’t need a main function explicitly. You can define any package entry points you want at the package config level. (setup.py, etc)

              example: What I meant was I prefer language that treat developers like adults. If I want ptrhon’s “ux” to hide some functions or objects I can do that with underscores, but nothing is private, a developer using my library can do whatever they want with it, access whatever internals they want (at their own risk of course)

  • Sinthesis@lemmy.today
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    19 days ago

    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)
    
  • onlinepersona@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    19 days ago

    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

    • Cratermaker@discuss.tchncs.de
      link
      fedilink
      arrow-up
      0
      ·
      19 days ago

      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.

    • MajorasMaskForever@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      19 days ago

      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

    • barsoap@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      19 days ago

      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”?

      It executes ld.so which will go through the ELF header, find all the libraries, resolve all dynamic symbols, then does some bookkeeping, and jump to main.

      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.

      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.

      • onlinepersona@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        19 days ago

        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

        • barsoap@lemm.ee
          link
          fedilink
          arrow-up
          0
          ·
          19 days ago

          Your ld.so contains:

          Entry point address: 0x1d780

          …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: _start is merely the default symbol name for the entry label, I’m sure nasm and/or ld have ways to set it to something different.

    • anton@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      0
      ·
      19 days ago

      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 to targets, one library and one executable.

    • bastion@feddit.nl
      link
      fedilink
      arrow-up
      0
      ·
      19 days ago

      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.

        • bastion@feddit.nl
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          19 days ago

          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:
              pass
          

          I was kinda lazy with the fuckery, tbh. I could have gotten much more confusing, but don’t have too much time today. :-)

          Maybe I should do a post in programmer humor about preventing arbitrary execution of your python code, and make it sound like it prevents security flaws. …which, technically, it does - if your code isn’t executing, and instead a useless infinite loop is executing, there’s nothing to exploit.

  • lmmarsano@lemmynsfw.com
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    19 days ago

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

  • embed_me@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    19 days ago

    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

    • addie@feddit.uk
      link
      fedilink
      arrow-up
      0
      ·
      19 days ago

      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.

      • ebc@lemmy.ca
        link
        fedilink
        arrow-up
        0
        ·
        18 days ago

        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.

        • addie@feddit.uk
          link
          fedilink
          arrow-up
          0
          ·
          18 days ago

          Enough of that crazy talk - plainly WheeledDeviceServiceFactoryBeanImpl is where the dependency injection annotations are placed. If you can decide what the code does without stepping through it with a debugger, and any backtrace doesn’t have at least two hundred lines of Spring boot, then plainly it isn’t enterprise enough.

          Fair enough, though. You can write stupid overly-abstract shit in any language, but Java does encourage it.

        • yogurtwrong@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          19 days ago

          I used it for a while and I think it’s been one of the best languages I’ve tried. C for example is too barebones for modern desktop apps. Apps written in Rust are great but most of the time, it’s just not worth the effort. And stuff like Python, JS is… uhh… where do I even begin

          I think Go hits the sweet spot between these. Unlike C, it at least has some simple error/panic mechanism, GC so you don’t have to worry about memory much and some modern features on top of that. And unlike Python it can actually create reasonably snappy programs.

          In any programming language, there will always be multiple cases where you need to link C libraries. CGo, although people don’t seem to be adoring it, is actually… okay? I mean of course it does still have some overhead but it’s still one of the nicer ways to link C libraries with your code. And Go being similar to C makes writing bindings so much easier

          Multithreading in Go is lovely. Or as I read somewhere “you merely adopted multithreading, I was born with it”

          Packaging is handled pretty nicely, pulling a library from the net is fairly trivial. And the standard directory structure for Go, although I’m not used to it, makes organizing stuff much easier and is easy to adopt

          As you would’ve guessed from the amount of times I mentioned C in this comment, I basically see Go as the “bigger C for different situations”

        • addie@feddit.uk
          link
          fedilink
          arrow-up
          0
          ·
          19 days ago

          Well now. My primary exposure to Go would be using it to take first place in my company’s ‘Advent of Code’ several years ago, in order to see what it was like, after which I’ve been pleased never to have to use it again. Some of our teams have used it to provide microservices - REST APIs that do database queries, some lightweight logic, and conversion to and from JSON - and my experience of working with that is that they’ve inexplicably managed to scatter all the logic among dozens of files, for what might be done with 80 lines of Python. I suspect the problem in that case is the developers, though.

          It has some good aspects - I like how easy it is to do a static build that can be deployed in a container.

          The actual language itself I find fairly abominable. The lack of exceptions means that error handling is all through everything, and not necessarily any better than other modern languages. The lack of overloads means that you’ll have multiple definitions of eg. Math.min cluttering things up. I don’t think the container classes are particularly good. The implementation of pointers seems solely implemented to let you have null pointer exceptions, it’s a pointless wart.

          If what you’re wanting to code is the kind of thing that Google do, in the exact same way that Google do it, and you have a team of hipsters who all know how it works, then it may be a fine choice. Otherwise I would probably recommend using something else.

          • silasmariner@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            19 days ago

            This is the most excellent summary of Go I have ever read. I agree with everything you’ve said, although as a fan of Scala and in particular its asynchronous programming ecosystem (cats for me, but I’ll forgive those who prefer the walled garden of zio) I would also add that, whilst its async model with go routines is generally pretty easy to use, it can shit the bed on some highly-concurrent workloads and fail to schedule stuff in time that it really should’ve, and because it’s such a mother-knows-best language there’s fuck all you can do to give higher priority to the threads that you happen to know need more TLC

          • sping@lemmy.sdf.org
            link
            fedilink
            English
            arrow-up
            0
            ·
            18 days ago

            I’m now 1 year in to working in Go having been mostly C++ and then mostly large-scale Python dev (with full type annotation).

            Frankly, I bristle now at people giving Python a hard time, having worked with Go and I now hate Go and the de-facto ethos that surrounds it. Python may be slow, but for a lot of use cases not in any way that matters and modern computers are very fast. Many problem areas are not performance-limited, and many performance problems are algorithmic, not from raw statement execution. I even rewrote an entire system in Python and made it use 20% of the CPU the former C++ solution used, while having much more functionality.

            The error returns drive me nuts. I looked around for explanations of the reasoning as I wasn’t seeing it, and only found bald assertions that exceptions get out of control and somehow error returns don’t. Meanwhile standard Go code is very awkward to read because almost every little trivial function calls becomes 4 lines of code, often to do nothing but propagate the error (and errors are just ignored if you forget…). With heavy use of context managers, my error and cancellation handling in Python was always clean, clear, and simple, with code that almost read like whiteboard pseudo-code.

            The select statement can be cool in Go, but then you realize that literally 98% of the times it’s used, it’s simply boilerplate code to (verbosely) handle cancellation semantics via the context object you have to pass everywhere. Again, literally code you just don’t need in exception-based languages with good structures to manage it like Python context managers.

            And every time you think “this is stupidly awkward and verbose, surely there’s a cleaner way to do this” you find people online advocating writing the same boilerplate code and passing it off as a virtue. e.g. get a value from a map and fall back to a default if it’s not there? Nope, not offering that, so everyone must write their own if foo, ok := m[k]; !ok {...} crap. Over and over and over again the answer is “just copy this chunk of code” rather than “standard libraries should provide these commonly needed utilities”. Of course we can do anything we want ourselves, it’s Turing Complete, but why would we want to perpetually reinvent these wheels?

            It’s an unpopular language, becoming less popular (at least by Google trends) and for good reason. I can see it working well for a narrow set of low level activities with extreme concurrency performance needs, but it’s not the only language that could handle that, and for everything else, I think it’s the wrong choice.

      • embed_me@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        19 days ago

        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

        • jadedwench [they/them]@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          0
          ·
          18 days ago

          Does Lua rank far below python for you? I have so much rage against it. At least with Python I don’t have to do a bunch of steps to just get it to do something. May take me a while to get through bad Python code, but Lua makes my eyes bleed and I begin to regret my life choices in trying to understand wtf these people wrote.

  • jjjalljs@ttrpg.network
    link
    fedilink
    arrow-up
    0
    ·
    20 days ago

    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.

  • JATth@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    19 days ago

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

    • YourShadowDani@lemm.ee
      link
      fedilink
      English
      arrow-up
      0
      ·
      19 days ago

      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)

      • JATth@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        19 days ago

        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.

  • Eager Eagle@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    20 days ago

    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.

  • driving_crooner@lemmy.eco.br
    link
    fedilink
    arrow-up
    0
    ·
    19 days ago

    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

    • Whelks_chance@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      18 days ago

      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.