Model definition: +1, Instead of "models" what about "orm"?
Database connection: +1 API usage: Object creation +1 API usage: Table-level functions +0 Instead of fiddling with objects_, just allow them to do what you plan later on, which is to assign a custom Manager class. This way, if the coder wants to add an 'objects' attribute, they can change the manager with 'manager = models.Manager()'. API usage: Overriding model methods (and pre- and post-save hooks) +0 (I think RJ is right though, that a more general event system would rock.) API usage: Overriding table-level functions +1, an ecstatic +1 API usage: Specifying lookups +0, I agree with Hugo #980, written by that brilliant coder, is better. Although, I do see the possible need for the Person.q stuff. I think it would be better just to make a "q" for each attribute in the model, so that you could do Person.first_name, instead of Person.q.first_name. Other "module"-level members: Automatic manipulators and ObjectDoesNotExist exception +0, it occurs to me that if you're going to go this far, why not get rid of "objects" entirely and allow it right off the Class? Otherwise, I'm afraid for consistancy you'll have to do Person.objects.DoesNotExist, and Person.objects.get_add_manipulator()
