The bigger use for if-name-is-main check is that you need it when using any library for multithreading / multiprocessing (threading / multiprocessing / asyncio / concurrent.futures). The way it works is that when creating a new thread/process, you point to a function defined in your code for the thread/process to work on, and if you don't have the if-name-is-main check then you would end up creating a fork-bomb, where each new thread/process would think it should run the main program and create new threads/processes infinitely.
Dude thank you so freaking much!!! IDK why this was so hard for others to explain in a simple video haha literally so many other videos have the music blaring, are reading from a script and just superfluously repeating things. This video made so much sense thank you again!!!!
normally in the module, you have function definitions. What you do in your module, you added a function call (subscribe() ). That's why when importing is being executed. It's for me strange practise (to add fucntion calls outside of functions inside your modules), but the rest is ok.
in my case if there are multiple functions, do I need to add if main in both the functions? def abc: ... if __name__ == 'main' : abc() def efg: ... if __name__ == 'main' : efg()
The most import reason to include name/main is to tell people your module is also an executable script, and if it is only a script, you can now use OO and functions to deal with your problem in a clear and SOLID manner. No more incomprehensible bash or, gasp, perl, scripts.
Correct me if I’m wrong. But if __name__ == __main__ should only be written if the part you are working on is a script. Not on a module ? Main == main app.
So, if you're saying that importing only a specific function like "from sample_module import subscribe" doesn't really save resources because python checks everything in a given module (in this case sample_module), then why not use "import *" every time? Is it just that when I import several libraries in this way, their functions may have the same names, which can lead to errors later? Thanks
actually, libraries have global variables that you won't know about unless you view their code and if by any accident you override said variables it can lead to the library not being useable (in that instance) also modules are huugee and flooding your namespace with so much is not good, import either the full module, eg, import tkinter as tk or import parts of it eg, from tkinter import Tk never import everything, import * is very respurse heavy as it takes up a lot of your memory.
if __name__ != 'name' : the code underneath it won't be excuted in the main module but outside the main module it is possible to use any element embraced by the if statement. am i right guys? i am not familiar with Python
The live template functionality is wack for me. It only works if I write "if main", not "main". And then of course I have to remove the "if" part of the code otherwise I get double ifs: "if if __name__ == "__main__:"
I enjoy your videos, but.... This particular video on the use of __main__ is for me, not very useful, and I never use this constuction. Let me explain. I use an "interactive environment". I never run scripts from the command line. In my REPL environment, any script can be the "main" script at any time. Therefore, using the __name__ = __main__ statement can never have any effect. However, I do have debugging techniques that comment and uncomment statements. That is more useful. Also, I generally debug one function at a time. When I do, I transfer the code in the function to its own module, and execute the statements one a time. This is far more effective than having a check for __main__ in every module. But still, maybe for some people who do execute scripts from the command line, this technique might actually be beneficial. I can't imagine using any computer language from the command line. An interactive environment, and if possible a visual environment is an absolute must. If a new language can't provide that it can't be of much use. Also, showing the data type for every variable (example - x:int = 85) or for arguments in a function is only marginally useful. I use Python because it allows me to get things done. I appreciate Python's flexibility in making me - the programmer - productive. My functions rarely take a single data type as an argument, and the same variable is often assigned different data types. Using data type descriptors is sometimes useful, but often, if used, would be inaccurate. If Python were to force the use of data type descriptors it would restrict the language to an unnecessary degree. So, I appreciate the use of some constructs in Python when they make sense, but I hope they never become more "pythonic" by making them mandatory.
I don't know who is copying who but there is the 3 videos of the same thing lolol. Not even kidding. All 3 of the videos also have lots of views lol. Ppl acting like they can code but doing it for youtube views.
The bigger use for if-name-is-main check is that you need it when using any library for multithreading / multiprocessing (threading / multiprocessing / asyncio / concurrent.futures). The way it works is that when creating a new thread/process, you point to a function defined in your code for the thread/process to work on, and if you don't have the if-name-is-main check then you would end up creating a fork-bomb, where each new thread/process would think it should run the main program and create new threads/processes infinitely.
Thanks man for info :)
Dude thank you so freaking much!!! IDK why this was so hard for others to explain in a simple video haha literally so many other videos have the music blaring, are reading from a script and just superfluously repeating things. This video made so much sense thank you again!!!!
Yeah, I think the worst thing to do in a tutorial is to put any kind of music in the background. I can't focus like that
Been stuck on this in a class for DAYS and just the first three minutes of thisvideo immediately cleared up so much that it was shocking. Thank you!
im new to python, and i was wondering why people use that. thanks for the tip
Thanks! Very clear!
this video makes so much sense.. better understanding now.. thanks :)
normally in the module, you have function definitions. What you do in your module, you added a function call (subscribe() ). That's why when importing is being executed. It's for me strange practise (to add fucntion calls outside of functions inside your modules), but the rest is ok.
in my case if there are multiple functions, do I need to add if main in both the functions?
def abc:
...
if __name__ == 'main' :
abc()
def efg:
...
if __name__ == 'main' :
efg()
I have a question. Does it affect the script's performance by adding it?
Very clear, thank you
Quality content as always
The most import reason to include name/main is to tell people your module is also an executable script, and if it is only a script, you can now use OO and functions to deal with your problem in a clear and SOLID manner. No more incomprehensible bash or, gasp, perl, scripts.
That's great 👍 👌
Correct me if I’m wrong. But if __name__ == __main__ should only be written if the part you are working on is a script. Not on a module ?
Main == main app.
How did you setup to auto-populate that!?
So, if you're saying that importing only a specific function like "from sample_module import subscribe" doesn't really save resources because python checks everything in a given module (in this case sample_module), then why not use "import *" every time?
Is it just that when I import several libraries in this way, their functions may have the same names, which can lead to errors later? Thanks
actually, libraries have global variables that you won't know about unless you view their code and if by any accident you override said variables it can lead to the library not being useable (in that instance)
also modules are huugee and flooding your namespace with so much is not good, import either the full module, eg, import tkinter as tk
or import parts of it eg, from tkinter import Tk
never import everything, import * is very respurse heavy as it takes up a lot of your memory.
As usual a clear and concise tutorial. Thank you ☺
Can you make a video about setting up pycharm with the new UI for python dev like main setting and stuff
I will make more videos about PyCharm soon. I made a video on NewUI, it's literally 1 button to set it up.
Nice video:D
if __name__ != 'name' :
the code underneath it won't be excuted in the main module but outside the main module it is possible to use any element embraced by the if statement. am i right guys? i am not familiar with Python
Do a video on your pycharm setup please
I will try :)
God video, som altid!
The live template functionality is wack for me. It only works if I write "if main", not "main". And then of course I have to remove the "if" part of the code otherwise I get double ifs: "if if __name__ == "__main__:"
5 years in and still to this day I wonder about name == main
Good day greetings
If this script is a program then run program code
I enjoy your videos, but....
This particular video on the use of __main__ is for me, not very useful, and I never use this constuction. Let me explain. I use an "interactive environment". I never run scripts from the command line. In my REPL environment, any script can be the "main" script at any time. Therefore, using the __name__ = __main__ statement can never have any effect.
However, I do have debugging techniques that comment and uncomment statements. That is more useful. Also, I generally debug one function at a time. When I do, I transfer the code in the function to its own module, and execute the statements one a time. This is far more effective than having a check for __main__ in every module.
But still, maybe for some people who do execute scripts from the command line, this technique might actually be beneficial. I can't imagine using any computer language from the command line. An interactive environment, and if possible a visual environment is an absolute must. If a new language can't provide that it can't be of much use.
Also, showing the data type for every variable (example - x:int = 85) or for arguments in a function is only marginally useful. I use Python because it allows me to get things done. I appreciate Python's flexibility in making me - the programmer - productive. My functions rarely take a single data type as an argument, and the same variable is often assigned different data types. Using data type descriptors is sometimes useful, but often, if used, would be inaccurate. If Python were to force the use of data type descriptors it would restrict the language to an unnecessary degree. So, I appreciate the use of some constructs in Python when they make sense, but I hope they never become more "pythonic" by making them mandatory.
I don't know who is copying who but there is the 3 videos of the same thing lolol. Not even kidding. All 3 of the videos also have lots of views lol. Ppl acting like they can code but doing it for youtube views.
pycharm is too much noise
nobody's asking you to use it
Hello
But only if you love Python.