On Mon, May 2, 2011 at 10:54 PM, Carl Meyer <c...@oddbird.net> wrote: > On 05/02/2011 07:15 AM, Russell Keith-Magee wrote: >>>> what do you think about deprecating AUTH_PROFILE_MODULE and .get_profile() >>>> or removing the suggestion to use it from the docs in 1.4 release? >>>> There are broader issues with extending User model but I think this one >>>> can be handled separately. >>> >>> -1 on deprecating it before having something better to replace it. >> >> Completely agreed. get_profile may not be ideal, but it's better than >> providing nothing, and cleaning up get_profile will be a logical >> extension of any good auth.User refactor. > > Deprecating get_profile() is pretty low on my priority list, but I'm a > bit confused by these two comments. What exactly does get_profile() > offer that needs to be "replaced" or is actually "better than providing > nothing"? Or, more specifically, better than recommending a > OneToOneField and the usual ORM accessor (even leaving aside the > multiple-profiles case)? In every way that I can see, it is worse than > that: it's a special case, requires additional cognitive overhead to > learn, more characters to type, more runtime processing, more code in > Django to maintain, and adds zero value. > > The only possible argument for it I can see is that it provides a > standardized way for reusable apps to get at a project's user profile > model. But given that no assumptions can be made about what is on the > profile model, the range of useful uses for that is pretty much limited > to one case: providing some pre-built URLs etc for creation and editing > of profiles; i.e. django-profiles. And even that case gains nothing from > AUTH_PROFILE_MODULE being a built-in feature of Django as opposed to an > external setting documented by django-profiles itself. > > I don't mind leaving get_profile() around, I guess, but IMO the best > argument that can be made for that is "it's useless but mostly harmless, > and it's not worth making people change their code to remove it." I'll > continue to recommend in IRC and elsewhere that people avoid using it.
"Better than nothing" was perhaps a bad choice of phrase on my part. My point is that it does serve a purpose, however tangential -- it provides an API hook that we can point at when someone says "How do I put custom data on my User object". For me, when combined with the fact that it's not hurting anyone to keep it around, this tangential documentation benefit is the reason to keep it around until we "fix" User -- even if we de-emphasise its use. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
