Absolute imports specify the complete path to the module, function, or path we want to import. If we need access to the Product class inside the products module, we could use any of these syntaxes to do an absolute import:

	import ecommerce.products
	product = ecommerce.products.Product()

or

	from ecommerce.products import Product
	product = Product()

or

	from ecommerce import products
	product = products.Product()

The import statements separate packages or modules using the period as a separator.

These statements will work from any module. We could instantiate a Product using this syntax in main.py, in the database module, or in either of the two payment modules. Indeed, so long as the packages are available to Python, it will be able to import them. For example, the packages can also be installed to the Python site packages folder, or the PYTHONPATH environment variable could be customized to dynamically tell Python what folders to search for packages and modules it is going to import.

So with these choices, which syntax do we choose? It depends on your personal taste and the application at hand. If there are dozens of classes and functions inside the products module that I want to use, I generally import the module name using the from ecommerce import products syntax and then access the individual classes using products.Product. If I only need one or two classes from the products module, I import them directly using the from ecommerce.proucts import Product syntax. I don't personally use the first syntax very often unless I have some kind of name conflict (for example, I need to access two completely different modules called products and I need to separate them). Do whatever you think makes your code look more elegant.

When working with related modules in a package, it seems kind of silly to specify the full path; we know what our parent module is named. This is where relative imports come in. Relative imports are basically a way of saying "find a class, function, or module as it is positioned relative to the current module". For example, if we are working in the products module and we want to import the Database class from the database module "next" to it, we could use a relative import:

	from .database import Database

The period in front of database says, "Use the database module inside the current package". In this case, the current package is the package containing the products.py file we are currently editing, that is, the ecommerce package.

If we were editing the paypal module inside the ecommerce.payments package, we would want to say, "Use the database package inside the parent package", instead. That is easily done with two periods:

	from ..database import Database

We can use more periods to go further up the hierarchy. Of course, we can also go down one side and back up the other. We don't have a deep enough example hierarchy to illustrate this properly, but the following would be a valid import if we had a ecommerce.contact package containing an email module and wanted to import the send_mail function into our paypal module:

	from ..contact.email import send_mail

This import uses two periods to say, "the parent of the payments package", then uses normal package.module syntax to go back "up" into the contact package.

Inside any one module, we can specify variables, classes, or functions. They can be a handy way of storing global state without namespace conflicts. For example, we have been importing the Database class into various modules and then instantiating it, but it might make more sense to have only one database object globally available from the database module. The database module might look like this:

	class Database:
		# the database implementation
		pass
		
	database = Database()

Then we can use any of the import methods we've discussed to access the database object, for example:

	from ecommerce.database import database

A problem with the above class is that the database object is created immediately when the module is first imported, which is usually when the program starts up. This isn't always ideal, since connecting to a database can take a while, slowing down startup, or the database connection information may not yet be available. We could delay creating the database until it is actually needed by calling an initialize_database function to create the module-level variable:

	class Database:
		# the database implementation
		pass
		
	database = None
	
	def initialize_database():
		global database
		database = Database()

The global keyword tells Python that the database variable inside initialize_database is the module-level one we just defined. If we had not specified the variable as global, Python would have created a new local variable that would be discarded when the method exits, leaving the module-level value unchanged.

As these two examples illustrate, all code in a module is executed immediately at the time it is imported. However, if it is inside a method or function, the function will be created, but its internal code will not be executed until the function is called. This can be a tricky thing for scripts (like the main script in our e-commerce example) that perform execution. Often, we will write a program that does something useful, and then later find that we want to import a function or class from that module in a different program. But as soon as we import it, any code at the module level is immediately executed. If we are not careful, we can end up running the first program when we really only meant to access a couple functions inside that module.

To solve this, we should always put our startup code in a function (conventionally called main) and only execute that function when we know we are executing as a script, but not when our code is being imported from a different script. But how do we know that?:

	class UsefulClass:
		'''This class might be useful to other modules.'''
		pass		
	def main():
		'''creates a useful class and does something with it for our 
	module.'''
		useful = UsefulClass()
	print(useful)
	
	if __name__ == "__main__":
		main()
		

Every module has a __name__ special variable (remember, Python uses double underscores for special variables, like a class's __init__ method) that specifies the name of the module when it was imported. But when the module is executed directly with python module.py, it is never imported, so the __name__ is set to the string "__main__". Make it a policy to wrap all your scripts in an if __name__ == "__main__": test, just in case you write a function you will find useful to be imported by other code someday.

So methods go in classes, which go in modules, which go in packages. Is that all there is to it?

Actually, no. That is the typical order of things in a Python program, but it's not the only possible layout. Classes can be defined anywhere. They are typically defined at the module level, but they can also be defined inside a function or method, like so:

	def format_string(string, formatter=None):
		'''Format a string using the formatter object, which
		is expected to have a format() method that accepts
		a string.'''
		class DefaultFormatter:
			'''Format a string in title case.'''
			def format(self, string):
				return str(string).title()
				
		if not formatter:
			formatter = DefaultFormatter()
			
		return formatter.format(string)	
		
	hello_string = "hello world, how are you today?"
	print(" input: " + hello_string)
	print("output: " + format_string(hello_string))

Output:

input: hello world, how are you today?
output: Hello World, How Are You Today?

The format_string function accepts a string and optional formatter object, and then applies the formatter to that string. If no formatter is supplied, it creates a formatter of its own as a local class and instantiates it. Since it is created inside the scope of the function, this class cannot be accessed from anywhere outside of that function. Similarly, functions can be defined inside other functions as well; in general, any Python statement can be executed at any time. These "inner" classes and functions are useful for "one-off" items that don't require or deserve their own scope at the module level, or only make sense inside a single method.