Re: deprecation of AUTH_PROFILE_MODULE

[Daniel Greenfeld]

I agree that email-as-username should be a built-in User abstract model (or 
something) in Django. It's an incredibly common use case and for once I 
think Django could use some additional functionality.

+1 to email as username model in core.

Danny

On Sunday, March 3, 2013 10:21:55 AM UTC-8, Florian Apolloner wrote:
>
> Hi Jacob,
>
> On Sunday, March 3, 2013 5:08:24 PM UTC+1, Jacob Kaplan-Moss wrote:
>>
>> I actually strongly disagree: I think Django *should* ship an 
>> "authenticate-using-email" system.
>>
>
> Out of curiosity, since I barely have this need by myself: Is it 
> "authenticate-using-email" or "use-email-as-username". Authentication via 
> Email can be done via a backend easily (though we should make the email 
> column unique then). So I am wondering what the main issue here is: is it 
> having username beeing a required field (an uuidv4 should suffice as a 
> workaround currently) or something different? 
>
> I can't promise it'd go in -- I'm not going to 
>> overrule a -1 from Florian by fiat -- but I think having a concrete 
>> patch on the table will make it easier to make a decision.
>
>
> No worries, if it would exist it would have been a -0.5; either way, a 
> concrete patch would certainly help. If it does make it into core I'd still 
> prefer the most minimal solution possible.
>
> Regarding the current proposal: Luke, can you tell us how your changes 
> would play with the current forms etc? Especially since some forms have a 
> hard coded dependency on a concrete user model (by design). I'd prefer not 
> to duplicate all those forms if somehow possible.
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecation of AUTH_PROFILE_MODULE

[Florian Apolloner]

Hi Jacob,

On Sunday, March 3, 2013 5:08:24 PM UTC+1, Jacob Kaplan-Moss wrote:
>
> I actually strongly disagree: I think Django *should* ship an 
> "authenticate-using-email" system.
>

Out of curiosity, since I barely have this need by myself: Is it 
"authenticate-using-email" or "use-email-as-username". Authentication via 
Email can be done via a backend easily (though we should make the email 
column unique then). So I am wondering what the main issue here is: is it 
having username beeing a required field (an uuidv4 should suffice as a 
workaround currently) or something different? 

I can't promise it'd go in -- I'm not going to 
> overrule a -1 from Florian by fiat -- but I think having a concrete 
> patch on the table will make it easier to make a decision.


No worries, if it would exist it would have been a -0.5; either way, a 
concrete patch would certainly help. If it does make it into core I'd still 
prefer the most minimal solution possible.

Regarding the current proposal: Luke, can you tell us how your changes 
would play with the current forms etc? Especially since some forms have a 
hard coded dependency on a concrete user model (by design). I'd prefer not 
to duplicate all those forms if somehow possible.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecation of AUTH_PROFILE_MODULE

[Jacob Kaplan-Moss]

On Fri, Mar 1, 2013 at 12:04 PM, Florian Apolloner
 wrote:
> Doing it outside of Django core if fine, inside core is -0 to -1 from me.

I actually strongly disagree: I think Django *should* ship an
"authenticate-using-email" system. It's *SUCH* a common desire, and
it's actually fairly tricky to get all the pieces in place to do it
right. I just cruised StackOverflow: it's asked a ton, and the answers
all have something not-quite-right about them, especially now that 1.5
has shipped.

So I'm +1 on including something in core. Luke, do you think you can
work up a patch? I can't promise it'd go in -- I'm not going to
overrule a -1 from Florian by fiat -- but I think having a concrete
patch on the table will make it easier to make a decision. So if you
don't mind doing a bit of "spec work" that'd probably give you us best
chances of getting this in.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecation of AUTH_PROFILE_MODULE

[Florian Apolloner]

Hi,

On Friday, March 1, 2013 9:00:28 PM UTC+1, Luke Sneeringer wrote:
>
> I'd be interested in actually doing this if folks on the list think it's a 
> good idea.
>

Doing it outside of Django core if fine, inside core is -0 to -1 from me.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecation of AUTH_PROFILE_MODULE

[Luke Sneeringer]

I do think that there's a pretty common "alternate use case" which we could 
support more easily. That's the use case where someone wants a User model that 
is either:

 * exactly like the Django User model, but with e-mail address as the unique 
identifying field instead of username
 * exactly like the above bullet, but with additional fields

The new 1.5 user customization makes adding fields to the user model a very 
trivial task, but it's still a lot of code to make e-mail addresses serve the 
function of usernames. You need to write the model, define USERNAME_FIELD, 
REQUIRED_FIELDS, and all the methods, which basically work almost identically 
to the auth.User reference implementation. It's also not very DRY.

I was considering writing an implementation of this, which I think would see a 
lot of use, and putting it up on PyPI, but it seems like something that would 
be even better if offered as part of Django itself.

Here is, I think, a way we could do it without breaking backwards compatibility:

 * Make an EmailBasedUser class which functions identically to User, except 
that email is the USERNAME_FIELD.
 * Make auth.User subclass EmailBasedUser, add `username` and set it as 
USERNAME_FIELD. User would still be AUTH_USER_MODEL.
 * Provide instructions in the documentation saying, "If you only want this one 
change, set AUTH_USER_MODEL to django.contrib.auth.EmailBasedUser

What is driving me here is that I think that this is a very common use case -- 
"I just want email addresses to function as usernames", and Django 1.5 still 
seems to require a lot of code to do that. It seems like it should be a quick 
change -- "just change this one setting" -- and it's not.

I'd be interested in actually doing this if folks on the list think it's a good 
idea.

Best Regards,
Luke Sneeringer

On Feb 27, 2013, at 4:47 PM, Russell Keith-Magee  
wrote:

> 
> 
> On Thu, Feb 28, 2013 at 4:24 AM, Alper Çuğun  wrote:
> 
> I looked into this today with 1.5 hitting and working on a project and this 
> seemed relevant.
> 
> On Monday, 2 May 2011 19:22:53 UTC+2, Carl Meyer wrote:
> 1. A specification of the minimal useful interface for a User (perhaps
> in the form of an abstract base model?) 
> 
> A User should not require a username. Usernames are a hideous remnant that 
> are impossible to justify on consumer facing websites. Authentication on 
> e-mail should be built-in if not the default.
>  
> A user *doesn't* require a username. It requires a unique identifying field. 
> However, by default, for historical reasons, the Django's built-in User model 
> has a username field. The whole point of the new feature is that specifying 
> an alternative is now a simple activity.
> 4. A migration path that meets our backwards-compatibility standards.
> 
> I saw the configurable User model that just landed in 1.5 but for a 
> non-library developer this is not very useful. It looks like a very large 
> amount of code for a rather small function.
> 
> It's not clear what you're suggesting here. Django has a built in User model. 
> That hasn't changed. You can now specify your own User model, and reuse large 
> parts of Django's built in parts if that is helpful in your circumstances. 
> What exactly is your concern here?
>  
> Furthermore: “If you intend to set AUTH_USER_MODEL, you should set it before 
> running manage.py syncdb for the first time.” is somewhat prohibitive to 
> existing projects. “you may need to look into using a migration tool like 
> South to ease the transition.” is not really a solution unless it is obvious 
> what changes should be made.
> 
> Well, this is a situation where we can't provide documentation, because 
> everyone's specific circumstances will be different. The best advice for 
> custom user models is "set it before you run syncdb", which is what we've 
> said. If you've already run syncdb, you'll need to migrate your models… but 
> exactly what that entails will entirely depend on what your own project has 
> done.
>  
> Also I don't understand: “This example illustrates how most of the components 
> work together, but is not intended to be copied directly into projects for 
> production use.” Code that is ready for production is the point of the 
> documentation for me. If this isn't, I think it's a documentation bug.
> 
> The point of that comment is that you shouldn't treat the documentation as a 
> cargo-cult, just copying and pasting. What is there will *work*. However, in 
> a real application, you need to pay attention to error messages, validation 
> conditions and so on.  
> 
> Yours,
> Russ Magee %-)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group 

Re: deprecation of AUTH_PROFILE_MODULE

[Russell Keith-Magee]

On Thu, Feb 28, 2013 at 4:24 AM, Alper Çuğun  wrote:

>
> I looked into this today with 1.5 hitting and working on a project and
> this seemed relevant.
>
> On Monday, 2 May 2011 19:22:53 UTC+2, Carl Meyer wrote:
>
>> 1. A specification of the minimal useful interface for a User (perhaps
>>
>> in the form of an abstract base model?)
>>
> A User should not require a username. Usernames are a hideous remnant that
> are impossible to justify on consumer facing websites. Authentication on
> e-mail should be built-in if not the default.
>
>
A user *doesn't* require a username. It requires a unique identifying
field. However, by default, for historical reasons, the Django's built-in
User model has a username field. The whole point of the new feature is that
specifying an alternative is now a simple activity.

> 4. A migration path that meets our backwards-compatibility standards.
>>
> I saw the configurable User model that just landed in 1.5 but for a
> non-library developer this is not very useful. It looks like a very large
> amount of code for a rather small function.
>

It's not clear what you're suggesting here. Django has a built in User
model. That hasn't changed. You can now specify your own User model, and
reuse large parts of Django's built in parts if that is helpful in your
circumstances. What exactly is your concern here?


> Furthermore: “If you intend to set 
> AUTH_USER_MODEL,
> you should set it before running manage.py syncdb for the first time.” is
> somewhat prohibitive to existing projects. “you may need to look into
> using a migration tool like South  to ease
> the transition.” is not really a solution unless it is obvious what
> changes should be made.
>

Well, this is a situation where we can't provide documentation, because
everyone's specific circumstances will be different. The best advice for
custom user models is "set it before you run syncdb", which is what we've
said. If you've already run syncdb, you'll need to migrate your models… but
exactly what that entails will entirely depend on what your own project has
done.


> Also I don't understand: “This example illustrates how most of the
> components work together, but is not intended to be copied directly into
> projects for production use.” Code that is ready for production is the
> point of the documentation for me. If this isn't, I think it's a
> documentation bug.
>

The point of that comment is that you shouldn't treat the documentation as
a cargo-cult, just copying and pasting. What is there will *work*. However,
in a real application, you need to pay attention to error messages,
validation conditions and so on.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecation of AUTH_PROFILE_MODULE

[Alper Çuğun]

I looked into this today with 1.5 hitting and working on a project and this 
seemed relevant.

On Monday, 2 May 2011 19:22:53 UTC+2, Carl Meyer wrote:

> 1. A specification of the minimal useful interface for a User (perhaps
>
> in the form of an abstract base model?) 
>
A User should not require a username. Usernames are a hideous remnant that 
are impossible to justify on consumer facing websites. Authentication on 
e-mail should be built-in if not the default.
 

> 4. A migration path that meets our backwards-compatibility standards.
>
I saw the configurable User model that just landed in 1.5 but for a 
non-library developer this is not very useful. It looks like a very large 
amount of code for a rather small function.

Furthermore: “If you intend to set 
AUTH_USER_MODEL,
 
you should set it before running manage.py syncdb for the first time.” is 
somewhat prohibitive to existing projects. “you may need to look into using 
a migration tool like South  to ease the 
transition.” is not really a solution unless it is obvious what changes 
should be made.

Also I don't understand: “This example illustrates how most of the 
components work together, but is not intended to be copied directly into 
projects for production use.” Code that is ready for production is the 
point of the documentation for me. If this isn't, I think it's a 
documentation bug.

Best,
Alper

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecation of AUTH_PROFILE_MODULE

[Russell Keith-Magee]

On Mon, May 2, 2011 at 10:54 PM, Carl Meyer  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.

Re: deprecation of AUTH_PROFILE_MODULE

[Russell Keith-Magee]

On Tue, May 3, 2011 at 1:28 AM, Shawn Milochik  wrote:
> Since it wasn't stated explicitly in that last wish-list, I'd like to add:
> No assumption that the primary key is an integer.

Certainly worth stating, but I don't think it's a major technical
challenge. An abstract base class approach should allow for the
concrete class to define the primary key type that is in 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.

Re: deprecation of AUTH_PROFILE_MODULE

[Jannis Leidel]

On 02.05.2011, at 19:22, Carl Meyer wrote:

> On 05/02/2011 11:38 AM, Jeremy Dunck wrote:
>> Given a blank slate, what would Auth look like these days?  And can we
>> work towards that?
> 
> Now, why you gotta get all constructive and forward-thinking and stuff? ;-)
> 
> Here's my list of core ideal-contrib.auth desiderata that I keep seeing
> crop up in related threads:
> 
> 1. A specification of the minimal useful interface for a User (perhaps
> in the form of an abstract base model?)
> 
> 2. A way to provide your own User class that extends the minimal spec,
> in a single table (i.e. MTI need not apply).
> 
> 3. A way for reusable apps to access and point foreign keys at the User
> model (solutions that involve magically transporting models into other
> modules need not apply - Django's been there, not going back).

As I've said before in person and on IRC, 2. and 3. will most likely be
possible with the app-loading branch. It introduces a notion of an app
class that would (among other things) allow to override the default auth
app by mimicking its API.

This is done by simply telling the app cache to consider a different app
as the app with the "auth" app label. E.g.:

$ cat myapp/models.py
from django.db import models
from django.contrib.auth.models import BaseUser # abstract base user

class User(BaseUser):
middle_name = models.TextField()

class Meta:
verbose_name = "My user"

$ cat myapp/app.py
from django import apps

class MyAuthApp(apps.App):

class Meta:
label = 'auth'
db_prefix = 'auth'

Then, in good tradition of duck typing, we use models.ForeignKey('auth.User')
to point to that custom user class, forcing the app cache to return the
myapp.models.User class.

> 4. A migration path that meets our backwards-compatibility standards.

As far as I understand there is little effort needed to split the User
model in an abstract base class and a concrete implementation that is
similar to the current class. Whether this needs some kind of migration
path is a different story.

Jannis

-- 
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.

Re: deprecation of AUTH_PROFILE_MODULE

[Shawn Milochik]

Since it wasn't stated explicitly in that last wish-list, I'd like to 
add: No assumption that the primary key is an integer.


--
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.

Re: deprecation of AUTH_PROFILE_MODULE

[Carl Meyer]

On 05/02/2011 11:38 AM, Jeremy Dunck wrote:
> Given a blank slate, what would Auth look like these days?  And can we
> work towards that?

Now, why you gotta get all constructive and forward-thinking and stuff? ;-)

Here's my list of core ideal-contrib.auth desiderata that I keep seeing
crop up in related threads:

1. A specification of the minimal useful interface for a User (perhaps
in the form of an abstract base model?)

2. A way to provide your own User class that extends the minimal spec,
in a single table (i.e. MTI need not apply).

3. A way for reusable apps to access and point foreign keys at the User
model (solutions that involve magically transporting models into other
modules need not apply - Django's been there, not going back).

4. A migration path that meets our backwards-compatibility standards.

Abstract base models already can handle 1 & 2, but if we take that
approach we still lack solid proposals for 3 & 4. And of course there
are many questions left untouched here (groups? permissions?), but these
are the core elements that I don't think I've heard much, if any,
disagreement on. I'd be interested to know if anyone sees a problem with
any of the above, or what people would add as core requirements.

Carl

-- 
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.

Re: deprecation of AUTH_PROFILE_MODULE

[Jeremy Dunck]

On Mon, May 2, 2011 at 9:54 AM, Carl Meyer  wrote:
...
> 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.

Given a blank slate, what would Auth look like these days?  And can we
work towards that?

-- 
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.

Re: deprecation of AUTH_PROFILE_MODULE

[Carl Meyer]

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.

Carl

-- 
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.

Re: deprecation of AUTH_PROFILE_MODULE

[Russell Keith-Magee]

On Mon, May 2, 2011 at 1:40 AM, Karen Tracey  wrote:
> On Sun, May 1, 2011 at 12:39 PM, Mikhail Korobov 
> wrote:
>>
>> Hi folks,
>> 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.

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.

Re: deprecation of AUTH_PROFILE_MODULE

[Karen Tracey]

On Sun, May 1, 2011 at 12:39 PM, Mikhail Korobov wrote:

> Hi folks,
>
> 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.

Karen

-- 
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.