Can I just get this straight : You still want to make a 'fake' module, a 'fake' class etc?
Why can't we just allow the model class defined by the user to be used? This would get over all of the visibility issues with the wierdo MODULE_CONSTANTS stuff, the way you have to import things inside functions etc. I'm really hoping that this isn't just some taste issue with classmethods. Tbh, I can't really see the point in this change if it isn't going to go the whole distance and eliminate the magic class at the very least. It also seems like real (inheritance-based) mixins would be really annoying using this method. At the moment as far as I understand it, you are just changing the location of the django.models import hook, and thus the name of the magic modules. Not really getting rid of much confusing magic at all, AFAICS. If we are going to make a lot of model changes, can we do it in a branch so it isn't a fait accompli on trunk and we can put in the different changes that are pending - I currently have mutually-referential stuff subsuming #746, and I have half a stab at core fields removal, and then I want to do 'proper' subclassing. The problem is that these are reasonably 'involved' changes that I think would be better done on a branch. I've tried doing these kinds of changes as private svk branches, but they just have no visibility - and they aren't really suited to being patches either - very non-localized.
