Re: AbstractUser to get more abstract

On Wed, Sep 18, 2013 at 1:27 PM, Luke Sneeringer wrote: > Russell, > I would *love* to do the work for the email-login analogue you describe. > I actually proposed just such a thing a few months ago but was rebuffed. > I'm sorry to hear this. Out of interest, did a member of

Re: AbstractUser to get more abstract

Russell, I would love to do the work for the email-login analogue you describe. I actually proposed just such a thing a few months ago but was rebuffed. However, I think this would be extremely useful. Also, I am, in fact, looking to get involved with Django development, as I haven't quite

Re: AbstractUser to get more abstract

Hi all It's great to see this discussion is happening -- however, given that we're debating the merits of different architectural approaches, with the aim of presenting a single approach for final inclusion in Django master, it would be worthwhile formalising the discussion. This is something

Re: AbstractUser to get more abstract

Hi Aaron, The motivation? Simple practicality. contrib.auth ships with a known manifest of models. If you add extra User models to contrib.auth, *every* Django project in existence will gain extra User models -- unless we develop a whole lot of extra infrastructure to *not* install certain

Re: Question about new tests

Hi Justin, many core developers haven't been at DjangoCon US, so would you mind to summarize a few things like: What is the roadmap, how do you plan to tackle things; who is involved + whatever else you think would be nice to know for someone who more or less heard the first time of this from

Re: AbstractUser to get more abstract

Russel, I'm curious if you could expand/explain your motivation on having this implemented as a separate contrib application rather than including it with django.contrib.auth On Thursday, September 12, 2013 5:41:29 PM UTC-6, Russell Keith-Magee wrote: > > > On Fri, Sep 13, 2013 at 4:44 AM,

Question about new tests

I'm working on the #unsetting project (ie, making all of Django's internals work without having to import the settings global). We have two key areas that now seem to work without running settings: mail and templating. I want to demonstrate these with tests. Where shall I put these tests? 1)

Re: AbstractUser to get more abstract

Hi Jorge - Thanks for the response. Rookie mistake: I had cloned from 1.6.x stable instead of master, the branch is now fixed to be branched from django/master from 10 minutes ago, that should resolve your conflicts. In terms of API, the API I went with is basically identical to the API used

Re: AbstractUser to get more abstract

Up front, I'm one of the developers of django-authtools I'm feel strongly that a new contrib application is the wrong way to accomplish this. Based on my memory of auth and django-authtools, most of `auth` will just work with the AbstractEmailUser class provided by django-authtools. Why not

Re: AbstractUser to get more abstract

Quick addendum: I forgot that django-libtech-emailuser does not use an AbstractUser intermediary step, it simply has one model. My approach has an abstract model, just like auth.User, with a concrete model that inherits from it and is swappable. -Tim On Tuesday, September 17, 2013 10:46:32

Re: Benchmarking 1.5 vs 1.6

I applied the patch with comment modification to 1.6.x and master. It seems the change did a lot of good to all of query benchmarks. Most 1.6.x ORM results are now 1.1 to 1.3x faster than in 1.5.x. Full results in the end of this post. There is still some problems, template rendering seems to

Re: Benchmarking 1.5 vs 1.6

It may be useful to place a comment where @wraps was removed, lest some later do-gooder "fix" it. On Sep 17, 2013, at 12:06 AM, Marc Tamlyn wrote: > Can't say I'm hugely worried about perfect tracebacks and introspection with > internal kind of functions here if it

Re: AbstractUser to get more abstract

Hi Tim. Thanks for posting this here. I was not aware of this ticket. Thank you also for taking the initiative and starting moving on this front. First of all, like you, I'm also recent in Django dev. This means that most likely, we will both make mistakes in the approach. The important is that

Re: Benchmarking 1.5 vs 1.6

Can't say I'm hugely worried about perfect tracebacks and introspection with internal kind of functions here if it affects performance. The patch looks good. I'd add a comment to say why we're not using @wraps in that context though so someone doesn't go back and add it. On 17 Sep 2013 07:57,

Re: Benchmarking 1.5 vs 1.6

I did some investigation to query_iterator, and most of the slowdown is caused by functools.wraps. When used in nested context @wraps seems to be really slow. For example, try this with and without @wraps: http://pastebin.com/5ejAKuKd Should we care about this slowdown? Can we do without