Re: AbstractUser to get more abstract

[Luke Sneeringer]

Good evening, Russell, et. al.,
I had some time this afternoon. :-) Since there are already a couple of 
reference implementations for how to do this with an e-mail app, I decided to 
take a crack at an implementation that would include an EmailUser within the 
base auth app. I understand we've far from decided on a method, and I still 
stand by my promise to do whatever Russell decides, but I figured code to look 
at would be a good thing, and that it would give me a better idea of the task.

Here's the branch: 
https://github.com/lukesneeringer/django/tree/ticket-20824-noemailapp

I have a few observations and self-criticisms:

The big advantage, as I see it, to this approach over a separate-app approach 
is that it drastically reduces code duplication. Forms, the admin, etc., all 
use the same classes they did before, just those classes are now a bit more 
aware of what the USERNAME_FIELD and REQUIRED_FIELDS are. This is really the 
reason I believe this to be the correct approach. A separate app would have to 
be maintained, well, separately. :-)
I have a few criticisms of my approach, now that I've had a chance to see it in 
action:
The create_user and create_superuser methods on UserManager were a bit of a 
land mine. The current (1.6) implementation takes username, email, and password 
as positional arguments, and making this into an all-kwarg approach would break 
back-compat. I landed on a solution, but I'm not sure it's the right one.
In order to maintain the form error message but not have the form itself be 
opinionated about the presence of "username", I removed the explicit validator 
on the form, simply letting ModelForm outsource it to the Model. This provides 
the same error message for both invalid and duplicate usernames / e-mail 
addresses (as appropriate). I think this actually might be a *good* thing 
(again, code duplication is reduced), but I don't really know if there's some 
reason why it was constructed the way it was before.
There's a special message for duplicate usernames ("A user with that username 
already exists."), and it's not a trivial thing to just make an e-mail address 
correlate because of internationalization. I reverted to the previous message, 
which was translated ("Please correct the duplicate data for email, which must 
be unique."), because I really don't know what the appropriate procedure is 
here. (This would be an issue with a separate-app approach too, but it's on my 
list of "things I didn't know".)
In starting to write tests (not committed), I hit an interesting situation 
where overwriting AUTH_USER_MODEL using override_settings may not be 
sufficient, which is an issue I would need to figure out. I expect this would 
not be a problem in an email_auth app, since the model wouldn't be loaded until 
after the override.

Russell, I definitely understand that you're still not sold on this method. I 
think that at this point, I've made my case, and if you're still not sold, I'm 
ready to coalesce the email_auth app implementations (two have been offered) 
and get that tip-top, tested, and documented.

Thoughts?

L

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Hyperlink CSS on djangoproject.com

[Marc Tamlyn]

As someone who has color blindness (off the top of my head I can't remember
the exact condition, but it's not simple red-green that 1 in 8 men have) it
looks fine to me. Personally I like the distinction between the external
and internal links.

My guidance for people is generally that if you aren't using the actual
colour to denote meaning (eg Red is bad), and the colours still appear
different in monochrome, then chances are everyone can see it OK. Maybe not
as clear as you, but OK enough.

It's also worth noting that colour vision problems can on occasions make
things *more* noticeable, depending on the colours and the person.

Marc
On 24 Sep 2013 20:50, "Daniele Procida"  wrote:

> On djangoproject.com and the docs in particular, we don't underline
> hyperlinks, though we do, with dots, if it's a hyperlink to a class or
> function or module.
>
> That means users need to rely on the colour of the text to determine
> whether something is a link or not.
>
> It works fine for me, but I don't know how well it will work for
> colourblind users (I tested it using a simulator - <
> http://colorfilter.wickline.org/?a=1;r=;l=9;j=1;i=1;u=https%3A//docs.djangoproject.com/en/dev/topics/performance;t=n>
> and it wasn't actually too bad in that).
>
> Is there any reason not to have all links underlined, in the interestes of
> improved accessibility?
>
> Daniele
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Hyperlink CSS on djangoproject.com

[Daniele Procida]

On djangoproject.com and the docs in particular, we don't underline hyperlinks, 
though we do, with dots, if it's a hyperlink to a class or function or module.

That means users need to rely on the colour of the text to determine whether 
something is a link or not. 

It works fine for me, but I don't know how well it will work for colourblind 
users (I tested it using a simulator - 

 and it wasn't actually too bad in that).

Is there any reason not to have all links underlined, in the interestes of 
improved accessibility?

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Tom Evans]

On Mon, Sep 23, 2013 at 5:55 AM, Anssi Kääriäinen
 wrote:
> On 09/20/2013 06:29 PM, Tom Evans wrote:
>>
>> On Fri, Sep 20, 2013 at 4:13 PM, Florian Apolloner
>>  wrote:

 It seems more sensible to hook something that has the lifetime of the
 request to the request, rather than stick it in TLS, keyed to the
 thread serving the request.
>>>
>>>
>>> Jupp, sadly I don't see a sensible way around thread local storage here
>>> :(
>>>
>> All good points, I just have this mental "HMM" when I see TLS as the
>> solution for anything. TLS is already used for things like the
>> language code of the current request, which avoids you having to pass
>> around a state object or passing down lang_code all down the stack,
>> but means that things like URL reversing and resolving benchmarks are
>> slow (O(n²)) with USE_I18N on.
>
>
> Huh? What is the n here? And why would passing the lang_code down the stack
> help?
>
>  - Anssi

n is the number of URLs.

In LocaleRegexProvider get_language() is called each time the reqexp
is requested - not just each time the regexp is compiled.
LocaleRegexProvider being the base class of RegexURLPattern and
RegexURLResolver

https://github.com/django/django/blob/master/django/core/urlresolvers.py#L160

Each time get_language() is called you do a TLS get. If you have a
large number of URLs, get_language() is called once for each URL
pattern that is checked against the current URL. If you have thousands
of URLs, and the current URL does not match (or matches one of the
last ones listed), then you have thousands of unnecessary TLS fetches
per URL resolve.

The fetches are unnecessary since the layer above could look up the
current language once, and pass that down. That pattern would not
allow the magic for regex() to be hidden behind a @property, and so
instead expensive TLS lookups occur inside regex() instead of inside
the caller of regex().

See also "URL dispatcher slow?" from last October, and:
  http://mindref.blogspot.co.uk/2012/10/python-web-routing-benchmark.html

Cheers

Tom

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

[Stefano Crosta]

Hello all,

this thread as gone so fast that I didn't manage to catch up and jump in 
time probably, but I did write a contrib app for Email-only user model: 
https://bitbucket.org/3h/django-accounts

My experience: I had to copy-paste a LOT of code to be sure all works, 
definitely much more that I thought I would at the beginning, to get what 
sounded basic to me: a User model /without/ the annoying (to me) username.
Had I to do it again I would probably simply work on "save" to copy the 
email into the username and hack the form bit not to ask for a username.

It sounds to me like going the other way around (the current User model 
inherits from the email-only user model) would have been simpler, but I 
understand that the username model is the standard django one.

Anyway, as I said I feel I'm jumping in slightly too late but I hope that 
the following is somehow useful:

1. I also prefere user models without usernames
2. My implementation (could definitelyl have been better, but maybe it 
gives ideas as to what could be made more abstract?) 
https://bitbucket.org/3h/django-accounts and thus my experience/feedback on 
it (too complex to make wihtout copying a lot of Auth things along!)

I'll be eagerly following this thread to see where it gets, and hope to be 
able to contribute more.

Thanks!

Stefano

On Friday, September 20, 2013 6:45:52 PM UTC+2, tanderegg wrote:
>
> Hi Luke - 
>
> I just wanted to let you know that I've already started a patch on this, 
> you can see it here: 
> https://github.com/tanderegg/django/compare/ticket_20824_master  If you 
> want to reduce duplicated effort, please take a look at what I have so far 
> and let me know what you think!
>
> Russ, Aaron -
>
> I tend to agree with Russ here that it makes sense to keep auth_email as a 
> separate app, especially if swappable is not meant to be used on any model 
> other than auth.User.  If EmailUser was also put into auth, not only would 
> it create an unesseccary set of tables, it also would cause m2m accessor 
> clashes with groups and permissions.  Additionally, it provides a 
> "template" of sorts for others to refer to if they want to roll their own 
> user models.
>
> That said, even if we use a separate app, we might benefit from 
> refactoring AbstractUser a bit.  I could see the following chain:
>
> AbstractBaseUser -> 
> AbstractPermissionsUser (ass ins Permissions Mixin) -> 
> AbstractEmailUser (just adds email field and email_user method) -> 
> AbstractNamedUser (adds first_name and last_name) -> 
> AbstractUser (retains same API as before)
>
> The advantage of doing this would be to remove some code duplication from 
> auth_email.EmailUser, and to create a few more inheritance opportunities 
> for scenarios where someone wants a user with no name fields, or if they 
> want to implement their own naming conventions, or if they want permissions 
> but no email and name.
>
> Here's an example of what that might look like: 
> https://github.com/tanderegg/django/compare/ticket_20824_refactor_master  
> I also modified the UserManager class to support any of these abstract 
> models.
>
> The main issue with doing this is that email would now be required for all 
> users (which could be avoided by removing AbstractEmailUser from the 
> inheritance chain and adding an email field to AbstractUser), and to 
> maintain backwards compatibility, UserManager.create_user would require 
> passing the email twice, once as username and once as email, for any model 
> that uses email as the username (which could be avoided by overriding in a 
> sub class when using email as username).
>
> Not sure if this refactoring would help all that much in the grand scheme 
> of things though.
>
> -Tim
>
> On Thursday, September 12, 2013 4:44:53 PM UTC-4, Abdulaziz Alfoudari 
> wrote:
>>
>> This is a continuation of my post on 
>> stackoverflow
>> .
>>
>> With the introduction of Django 1.5, it was possible to create a custom 
>> User model which is flexible enough to have any user profile the developer 
>> wants created. However, looking at a very common problem which is using the 
>> email as the primary user identifier instead of username, the solution 
>> requires copying most of Django's internal definition of AbstractUser and 
>> that is only to remove the username field.
>>
>> A better solution in my opinion is make AbstractUser even more abstract 
>> by removing username field, and allowing the developer to explicitly 
>> specify the field to be used as the user identifier. This will require a 
>> tiny extra work for those that use the current default behavior, but it 
>> will also greatly reduce the work needed for the very common problem of 
>> using email as the user identifier.
>>
>> Please share your thoughts and opinions on this.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To