Python needs an actual default function
-
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.
Lol OK I was wondering how would this run
And yes you should!!
-
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?
-
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.wrote on last edited by [email protected]Btw,
ld.sois a symlink told-linux-x86-64.so.2at least on my system. It is an statically linked executable. Theld.sois, in simpler words, an interpreter for the ELF format and you can run it:ld.so --helpEntry point address: 0x1d780
Which seems to be contained in the only executable
sectionsegment ofld.soLOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000 0x0000000000028bb5 0x0000000000028bb5 R E 0x1000Edit: My understanding of this quite shallow; the above is a segment that in this case contains the entirety of the
.textsection. -
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?"
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.
-
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.
-
Tbh reserving "main" is just a hacky if not more so than checking
__name__if you actually understand language design.Reserving
mainis definitely more hacky. Try compiling multiple objects withmaindefined 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 ownmainwhile 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. -
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?
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'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 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. -
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?
wrote on last edited by [email protected]It is "built-in" as the name is part of python. However, Python runs top to bottom, rather than having a special entrypoint. So name is just a utility you can use in your design.
While it can be a good practice to define a main entrypoint, that's more of a design decision and not hard rule. Many applications would not benefit from it because there is only one way to actually call the application to begin with.
Edit: Also not a dumb question. All programming languages have unique elements to them due to how they were envisioned and or developed over time (Pythons 30 years old)
-
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...
wrote on last edited by [email protected]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
-
It is "built-in" as the name is part of python. However, Python runs top to bottom, rather than having a special entrypoint. So name is just a utility you can use in your design.
While it can be a good practice to define a main entrypoint, that's more of a design decision and not hard rule. Many applications would not benefit from it because there is only one way to actually call the application to begin with.
Edit: Also not a dumb question. All programming languages have unique elements to them due to how they were envisioned and or developed over time (Pythons 30 years old)
I really appreciate the explanation!
-
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.
How many lines are in a page?
-
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 -
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?
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
-
I'm not sure I'm following the implication. Name=main is for scripts primary, is it not?
I've never thought to add more than one of these conditionals anyway...
So you might have a script that does stuff as a library, and it should get environment variables and other info from the calling script. You use the same script for doing one off stuff on different computers.
So you make it do something slightly different or make it set it's path and look into the current folder when you run it directly. This change in logic could be in a few points in the script.
-
How do you feel about other peoples Go code?
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"
-
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
Like in every programming language, it depends who wrote the code. OK, *nearly every programming language, see: LISP.
You can write cryptic, write-only programs in about any language, but you can even write readable and maintainable PERL scripts (despite people claiming this to be impossible).
-
Like in every programming language, it depends who wrote the code. OK, *nearly every programming language, see: LISP.
You can write cryptic, write-only programs in about any language, but you can even write readable and maintainable PERL scripts (despite people claiming this to be impossible).
As much as I am inclined to agree with this, still can't
see: LISP
Also, see: Python with more than three lines of logic. I could suspect that's just the me-versus-whitespaces thing, but no, YAML files do not get me dizzy in under thirty seconds of reading. Van Rossum made a huge miscalculation here
-
That is not how Python works. There are very few languages that work by executing line-by-line anymore. Unix shell scripts are one of the few holdouts. JavaScript also does it to a certain extent; the browser starts executing line-by-line while a compiler step works in the background. Once the compiler is done, it starts execution of the compiled form right where the line-by-line execution left off. It helps JavaScript be more responsive since it doesn't have to wait for the compiler to finish.
wrote on last edited by [email protected]Unix shell scripts are one of the few holdouts.
I don't know if this applies to other shells, but bash will not only execute your script line-by-line, it will also read it line-by-line. Which means that you can modify the behavior of a running script by editing lines that have not yet been executed*. It's absolutely bonkers, and I'm sure that it has caused more than one system failure, during upgrades.
* For example, if you run the following script
echo "hello" sleep 5 echo "goodbye"and then edit the third line before the 5 second sleep has elapsed, then the modified line will be executed.
-
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.mincluttering 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.
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
