

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.
I mean no harm.
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.
Btw, ld.so
is a symlink to ld-linux-x86-64.so.2
at least on my system. It is an statically linked executable. The ld.so
is, in simpler words, an interpreter for the ELF format and you can run it:
ld.so --help
Entry point address: 0x1d780
Which seems to be contained in the only executable section segment of ld.so
LOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000
0x0000000000028bb5 0x0000000000028bb5 R E 0x1000
Edit: My understanding of this quite shallow; the above is a segment that in this case contains the entirety of the .text
section.
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 didn’t even think what the questionnaire was about, and filled the entire thing. It’s a rare thing to see for a FOSS project to ask what I’m staring at this very moment, how to make it better. But yes, the questionnaire was a bit oddly structured.
No mention of KDevelop? ;__;
I like it because it is the pretty much only FOSS graphical IDE where the edit-compile-debug cycle works. I’m been using it for last 10y for C/C++/Python, and it recently gained LSP support. (ported from Kate)