Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Python Conditional Check

Youssef Moustahib
Youssef Moustahib
7,779 Points

Can someone help?

Can someone explain this a bit more?

if __name__ == __main__

This is saying that if the script "app.py" is the main thing in this script, then run whatever else happens after the if statement? IF it isnt, then dont run it?

yeah pretty much, and if you want to use a function from this file in another file, you would use import and ImportedFileName.NameOfFunction() in the video the example was app.print_hello()

2 Answers

Jordan Hoover
seal-mask
.a{fill-rule:evenodd;}techdegree seal-36
Jordan Hoover
Python Web Development Techdegree Graduate 59,268 Points

name is a special variable. Basically, if the file is being run directly and not imported it will run the following code. There's an entire workshop on it at Treehouse, but for now that's really all you need to know.

Here's a StackOverflow link on it as well.

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.