If _Name_ == '_Main_'' Equivalent in Ruby

`if __name__ == '__main__'` equivalent in Ruby

From the Ruby I've seen out in the wild (granted, not a ton), this is not a standard Ruby design pattern. Modules and scripts are supposed to stay separate, so I wouldn't be surprised if there isn't really a good, clean way of doing this.

EDIT: Found it.

if __FILE__ == $0
    foo()
    bar()
end

But it's definitely not common.

Purpose of 'if __name__ == __main__:'

Well, imagine that someone else wants to use the functions in your module in their own program. They import your module... and it starts doing its own thing!

With the if __name__ == "__main__", this doesn't happen. Your module only "does its thing" if it's run as the main module. Otherwise it behaves like a library. It encourages code reuse by making it easier.

(As Sheng mentions, you may want to import the module into another script yourself for testing purposes.)

Python variables not defined after if __name__ == '__main__'

I think there are two parts to your issue. The first is "what's wrong with pcl in the current code?", and the second is "why do I need the if __name__ == "__main__" guard block at all?".

Lets address them in order. The problem with the pcl variable is that it is only defined in the if block, so if the module gets loaded without being run as a script (which is what sets __name__ == "__main__"), it will not be defined when the later code runs.

To fix this, you can change how your code is structured. The simplest fix would be to guard the other bits of the code that use pcl within an if __name__ == "__main__" block too (e.g. indent them all under the current block, perhaps). An alternative fix would be to put the code that uses pcl into functions (which can be declared outside the guard block), then call the functions from within an if __name__ == "__main__" block. That would look something like this:

def do_stuff_with_pcl(pcl):
    print(pcl)

if __name__ == "__main__":
    # multiprocessing code, etc
    pcl = ...
    do_stuff_with_pcl(pcl)

As for why the issue came up in the first place, the ultimate cause is using the multiprocessing module on Windows. You can read about the issue in the documentation.

When multiprocessing creates a new process for its Pool, it needs to initialize that process with a copy of the current module's state. Because Windows doesn't have fork (which copies the parent process's memory into a child process automatically), Python needs to set everything up from scratch. In each child process, it loads the module from its file, and if you the module's top-level code tries to create a new Pool, you'd have a recursive situation where each of the child process would start spawning a whole new set of child processes of its own.

The multiprocessing code has some guards against that, I think (so you won't fork bomb yourself out of simple carelessness), but you still need to do some of the work yourself too, by using if __name__ == "__main__" to guard any code that shouldn't be run in the child processes.

alternate to if __name__ == '__main__':

Python scripts are different than python modules. A script is the top level code executed by python and modules are anything else imported later. Scripts are always called __main__ while modules use their module or package name. That's usually any parent directories and the name of the .py file, minus its extension.

if __name__ == "__main__":

is a way to demark code that you only want run when a .py file is run as a top level script. Code inside this if is not run if the module is imported because an imported module can't be called "__main__".

This is import if, say, you run a script on Windows that also uses multiprocessing. Multiprocessing will re-import the top level script and you don't want that code running just on import.

Generally, if you want a .py file to run as a script and an imported module, you play the if __name__ == "__main__": game. If its always an imported module, you don't have that worry.

In your case, it looks like gui.py is supposed to be imported only, so there is no need for the if. If you take away the if the code will always run on import. license_code and activation_code will then be available for the other functions to use.

Is it common to write a lot of code under if __name__ == '__main__': statement

Like BusyAnt said, the common way to do it is

import xxx

def fun1()
def fun2()
...

def main():
    task = sys.argv[1]
    if task =='task1':
        do task1
    elif task == 'task2':
        do task2
    ...

if __name__ == '__main__':
    main()

The upside of this is it does not run on import, but main() can still be run from another module or file if so preferred.

node.js equivalent of python's if __name__ == '__main__'

The docs describe another way to do this which may be the preferred method:

When a file is run directly from Node, require.main is set to its module.

To take advantage of this, check if this module is the main module and, if so, call your main code:

function myMain() {
    // main code
}

if (require.main === module) {
    myMain();
}

EDIT: If you use this code in a browser, you will get a "Reference error" since "require" is not defined. To prevent this, use:

if (typeof require !== 'undefined' && require.main === module) {
    myMain();
}

Is There C equivalent to Python's: if __name__ == '__main__': to write main() at the top of the file?

You do need to make a forward declaration (if you want to keep main at start of file), as this code will be compiled and not executed. As the compiler compiles line by line, it won't know the signature of the function before reaching it.

People are used to develop more important functions at bottom of the file.

But how does compilation work ?

Compilation is in fact made in 2 steps.

1) Gcc (or whatever you use) will make a pre-compiled version of every file you have.

2) It links all those pre-compiled files into either, an executable, or a library file, etc...

Now that you know this, you can understand how it works:

• At first step, the compiler can only know functions / variables that are present in a single file, but has no idea about the others, so if you call a function that's not in the file ==> he's not happy and generate an "undeclared function" error. But if you provide him with a header file, you basically tell the compiler "don't mind about this function missing, I'll add it later, in another file, at linking time". So the compilers ignores the error.
• At second steps, when linking all files together, it will check once more, that you kept your promise, by giving him an implementation for the functions that were defined in your header files. Otherwise, you get another kind of error, like "could not find function XXX" (my error names aren't accurate, i haven't done C for a year now).

---

Related Topics