i dont get the point of this video

There is a really great explanation on hows and whys of the name == 'main' here: stackeroverflow.com

Basically, you (hopefully) won't always be programming a "simple", one-file scripts. Sometimes you will have .py files that can be used in other programs ( I guess you call these modules). Instead of just C/P the code from one file to another, you can import it (just like the: import app command, where app.py was imported to second_app.py.

In some cases, you would not like a piece of code to be executed autmotacally, unless you are running the file as a main file. Here, you could use conditional if name == 'main' to make sure that the piece of code won't run automatically, if the file is imported to another file that is being executed.

It has to do with using Flask to make an application website.

I do agree this topic can be thought better for sure....but i do think i got the main concept

I agree with ranitank . Also, I think the answers to the two questions in the first of this pair of videos do good jobs of explaining why this pair of videos was made/what they're trying to teach us, especially together: https://teamtreehouse.com/community/understanding-double-unders-main & https://teamtreehouse.com/community/double-unders

Summary of the discussions for those questions: For clarity below, when I say "top-level" script, I mean the file being directly run, which is the one whose name Python automatically sets to "main". By extension, "upper-level" refers to any code from top-level down to the level that calls or imports a script/file of interest.

Python automatically runs imported code as it goes through your script. The dunder check (e.g. if name == "main":/n/s/s/s/smain()) allows your script to circumvent the otherwise automatic execution of the main/principal part of a file by putting the principal part in a function usually called main() and having main() run only when the script is part the top-level (aka main) file (or when the specified by an upper-level file).

The way most of our projects, challenges, and workspace files have been and continues to be for at least a few more videos (I haven't gotten too far ahead) is not to include the dunder check and also to have the chunk of code that usually would be part of a main/principal function in normal Python programming instead be simply part of the principal script of the file. This is fine for now as what we do is simple and mostly for learning or testing code. So, our code files have been following a structure/order that looks like this:

1. import files (if any)
2. define classes (if any)
3. define functions (if any)
4. principal script of this file

What happens when such a file is imported (rather than directly run) is something like this:

1. (further) files (if any) are imported and run (side note for clarity: this is an imported script importing more files)
2. classes (if any) are defined (but instances are not (yet) created)
3. functions (if any) are defined (but calls are not (yet) made)
4. principal script of THIS file is run That means that the principal script of this file (which is NOT the top-level script in this scenario) will run regardless of whether this script is the top-level script or an imported script.

A common order/structure for Python scripts in the real world is:

1. import files (if any)
2. define classes (if any)
3. define functions (if any)
4. define main/principal function (most of what we've been putting in the principal script of our files would go here)
5. dunder check with some condition leading to the call for the main/principal function

When you import a script of this structure, "everything" in the imported script still runs. Of course, statements for UNsatisfied conditions don't run, which is standard and intuitive. Specifically, with the generic dunder check, when the script is imported, its name will not be "main", and the dunder check is NOT satisfied. As a result, the main/principal function will not run (unless specifically called by another function or script).

What that means is that:

1. (further) files (if any) are imported and run
2. classes (if any) are defined (but instances are not (yet) created)
3. functions (if any) are defined (but calls are not (yet) made)
4. main/principal function is defined (but it is not (yet) called)
5. The statements for whatever condition is met will be run. For the generic dunder check condition, the condition for running the main/principal function of this script would NOT be met if the script is imported (rather than directly run), so the main/principal function of this script will NOT be called (unless specified in an upper-level function or script). On the other hand, if this script were the top-level script, the main/principal function would be called. Note that any unconditional code or code for satisfied conditions will run. Specifically, all further files (if any) still have been imported and run, and all classes and functions (if any) in the imported script still have been defined as they are outside of the unsatisfied condition/are not conditional. These importations and definitions allow upper-level functions and scripts to use the files, classes, and functions imported or defined in this file. Whether specific instances, automatic or not, are created or run is independent of their importations or definitions.

They should double the length of this course and explain it better.

why didn't they just figure out a way to incorporate "file name" into the syntax? I had no idea that that's what "name/main" was referring to until reading a bunch of people's responses.