somewhere else (and we will soon in this we'll see the output of its test code every time the file is imported that' not very good software citizenshipthoughclient programs probably don' care about our internal tests and won' want to see our output mixed in with their own although we could split the test code off into separate fileit' often more convenient to code tests in the same file as the items to be tested it would be better to arrange to run the test statements at the bottom only when the file is run for testingnot when the file is imported that' exactly what the module __name__ check is designed foras you learned in the preceding part of this book here' what this addition looks like--add the require test and indent your self-test codeallow this file to be imported as well as run/tested class persondef __init__(selfnamejob=nonepay= )self name name self job job self pay pay if __name__ ='__main__'when run for testing only self-test code bob person('bob smith'sue person('sue jones'job='dev'pay= print(bob namebob payprint(sue namesue paynowwe get exactly the behavior we're after--running the file as top-level script tests it because its __name__ is __main__but importing it as library of classes later does notc:\codeperson py bob smith sue jones :\codepython python ( :bd afb ebf sep : : import person when importedthe file now defines the classbut does not use it when run directlythis file creates two instances of our class as beforeand prints two attributes of eachagainbecause each instance is an independent namespace objectthe values of their attributes differ version portabilityprints all of this code works on both python and xbut ' running it under python xand few of its outputs use print function calls with multiple arguments as explained in this means that some of its outputs may vary slightly under python if you run under the code will work as isbut you'll notice step making instances