> Oh, okay. Yeah, that's quite different. I'm not convinced that should go > into Django. Again, there's a consistency thing: we present the object / > class type that is asked for, not some transparently descended version.
I think my explanation may have been a bit off... > The use-case for the pure-Python inheritance that has been floating > around is the case when you want to, say, use a different User manager > in your own views. You don't want to change the auth app's behaviour in, > say, admin, but you'd prefer a different default when you're using it. > So you subclass User, using Python-only inheritance, add a new default > manager and then actually use the subclass, rather than User in your > code. ....because this sounds like exactly how I want to use this feature. I subclass auth.User and add my own managers/methods/etc, and use this subclass in my own code. But if someone creates a new instance of auth.User via the standard class, it should also show up in queries posed through my subclass. Likewise, if I add a new user through my special subclass, it will show up as an ordinary user to e.g. the admin interface. So I'm not trying to add anything magical - the "virtual subclass" is simply a "facade" or "wrapper" around the data in the base class table that presents a modified interface. Yikes, there's that naming problem again... > Still, I wouldn't let that hold things up. I'll think about it and come > up with a name later on, unless a better option appears beforehand. Originally I named it "use_superclass_table" but decided that was just too ugly to deal with. "interface_only"? Glad not to be the one stuck making that decision :-) Thanks for all your feedback, I'll get some code into trac tonight. Ryan -- Ryan Kelly http://www.rfk.id.au | This message is digitally signed. Please visit [email protected] | http://www.rfk.id.au/ramblings/gpg/ for details
signature.asc
Description: This is a digitally signed message part
