There are a fairly large number of Python ORM projects. A list of these can be found at https://wiki.python.org/moin/HigherLevelDatabaseProgramming.

We're going to pick just one of these as an example. We'll use SQLAlchemy because it offers us a number of features and is reasonably popular. As with many things, there's no best; other ORM layers have different advantages and disadvantages.

Because of the popularity of using a relational database to support web development, web frameworks often include ORM layers. Django has its own ORM layer, as does web.py. In some cases, we can tease the ORMs out of the larger framework. However, it seems simpler to work with a standalone ORM.

The documentation, installation guide, and code for SQLAlchemy is available at http://www.sqlalchemy.org. When installing, using --without-cextensions can simplify the process if the high-performance optimizations aren't required.

It's important to note that SQLAlchemy can completely replace all of an application's SQL statements with first-class Python constructs. This has the profound advantage of allowing us to write applications in a single language, Python, even though a second language, SQL, is used under the hood as part of the data access layer. This can save some complexity in the development and debugging stages.

This does not, however, remove the obligation to understand the underlying SQL database constraints and how our design must fit within these constraints. An ORM layer doesn't magically obviate the design considerations. It merely changes the implementation language from SQL to Python.

We'll design an ORM-friendly class in the next section.