iBatis binds SQL DML (or SQL definitions) in an XML file. It specifically focuses on matching between SQL and some object model defined elsewhere.
SQL Alchemy can do this - but it's not a very complete solution. Like iBatis, you can simply have SQL table definitions and a mapping between tables and Python class definitions.
More importantly, this is a class definition, which is also a SQL database definition. If the class definition generates an SQL SQL table, as well as query and DML processing, this is much more complete.
I flip flop between SQLAlchemy and Django ORM. SQLAlchemy can be used in iBatis. But I prefer to make the design of the object central and leave the implementation of SQL from the objects a set of tools.
I use SQLAlchemy for large, batch, standalone projects. DB Loads, schema transforms, DW reports, etc. work well. These projects focus on the relational presentation of data, rather than the object model. Generated SQL can, for example, move to PL / SQL stored procedures.
I use Django for web applications using my built-in ORM features. You can, with little work, separate Django ORM from the rest of the Django environment. You can provide global settings to bind your application to a specific database without using a separate settings module.
Django includes a number of common relationships (Foreign Key, Many-to-Many, One-to-One) for which it can control the implementation of SQL. It generates key and index definitions for the attached database.
If your problem is mostly object-oriented, and the database is used for preservation, then the almost transparent ORM Django layer has advantages.
If your problem is largely relational, with central processing of SQL, then the ability to view the generated SQL in SQLAlchemy has advantages.