- cross-posted to:
- programmerhumor@lemmy.ml
- cross-posted to:
- programmerhumor@lemmy.ml
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?
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 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()?
I remember how weird this looked the first time I saw it and while I may now understand it, it still looks jank af
Python: I’m so readable that I’m practically executable pseudo-code
Also Python:
if __name__ == '__main__':. . .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?
The main two reasons that I can think of to include this even when you have no intention of importing this as a library are:
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.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. 🤷♂️
Now think about this, you have logic that doesn’t make sense when run directly, but you need it to be a library.
You have multiple name=main statements in some of your functions
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.
Heard of it, was too lazy to do it that way.
To be fair I now do it that way, but not when I was learning Python.
What is the point of this?
Not having tons of code in one if statement, but in a function.
And scope. Variables declared in the if can be read everywhere, variables declared in the function are limited to that function.
I thought you were saying to literally use
def main(): pass, that’s why I was confusedOh, no, that’s just the usual placeholder. Though, … would also be valid iirc, and would fit better as a “TODO” placeholder
custom bin folders are a realm no God dares to tread
I can and I do
*trollface*
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.
As someone in academia who writes code, I can confirm.
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?
the best thing is when not even the author knows the correct order of running the cells; because of course it isn’t top-to-bottom.
Yeah, and also zero dependency management, so you are free to figure out what combination of Python, Tensorflow and Keras will make it not throw random exceptions.
And don’t forget the number one rule: you must use all the graphing libraries, all the time.
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