[zzzeek]

that idea has come up on many occasions and was seriously discussed some years ago. I don't think it's ever happening in that specific form; mostly because it would require that the Django ORM's behavior and usage contract not change at all in order to support backwards compatibility. This would be a very large task, at the very least for Django and probably for us as we make adjustments to support them. The feel and behavior of Django's ORM would invariably change quite palpably - even if you can get every function input and output to match, you still have what it looks like when you get a stack trace, an error message, etc. Django users would see lots of unfamiliar "sqlalchemy" lines in these stack traces and tracking down issues would then involve both Django and SQLAlchemy devs. Performance would also be a concern - keeping behavior exactly as is within Django might require some odd workarounds or additional logic which could prove to be complex and/or less performant.

That said, I have on occasion floated an alternative idea, which is to basically port the Django configurational and query system to SQLAlchemy entirely, doing away with full backwards compatibility and essentially providing a "transitional" platform, where you take an existing Django application and basically run it on top of a new ORM layer that actually uses the SQLAlchemy Session and unit of work model, but the majority of the Django configuration and queryset behavior remains available, thus making porting a relatively painless process (but still, there'd be a porting process). This approach has two advantages. One is, it's actually doable, we're providing a new platform and not trying to duplicate an existing one. The other is, we're actually delivering to a Django application some of the biggest advantages SQLAlchemy has, which are namely the ORM features like unit of work/identity map, the instrumentation model including collections and eager loading support, and inheritance support.

Nobody has time / motivation for that idea either, but I think if it ever happened, it would be more pragmatic.