On Fri, Mar 9, 2012 at 3:36 PM, Luke Plant <l.plant...@cantab.net> wrote: > What you are really saying is this: being pragmatic means that we > prioritise *your* immediate need above the need to keep the code and the > docs maintainable, and above the need to maintain compatibility with > existing installations. > > There are a million-and-one hacks we would add if we took that approach, > and Django would have a million-and-one more bugs, or possibly much > worse - if you add just 10 boolean switches like the one you suggested > in an earlier email, you've got over 1000 combinations to test and > debug. The only way to avoid that in a framework like Django is well > defined APIs for components. No-one has brought such a thing to the > table and seen it through, that's why it hasn't come in. > > I believe that all the problems you have can be solved already: > > - you can write your own authentication backend to authenticate > by email > > - you can write your own login and account creation views > > - you can even override admin views by inserting items into > urls.py >
Even with these things, you are limited by the length of the username field, the length of the email field, and the arbitrary restrictions on what consists a username. The length restrictions could be fixed straight away, and a note added to the next relnotes informing users that the field has changed in size. If they do not update their DB structure, then depending on the database used, they will either get errors when a field value is longer than the old limit, or silent truncation. It's not ideal, but it doesn't cause any major problems for anyone who reads the relnotes, and it will have to be done at some point anyway. Even if Django did have schema migrations, the same behaviour would occur for anyone who read the relnotes and did not apply the migration, and many users with 'interesting' DB structures would not be able to simply apply schema migrations either, so they would have to do it by hand anyway. It feels to me that only fear of change and how to manage that change is what is stopping d.c.auth from being fixed. > > Yes, these are all more-or-less hacky. And they have problems. For > instance, what if you have two accounts with the same email address? (I > have that in some of my Django projects, BTW). The current code allows > it, so we can't change anything that would make it impossible, at either > the DB level or the Python level. This is the kind of issue that means > you can't just use the existing models. > Good for you! I don't see that as an issue. If you are using email address as a unique name for identifying a user, we already have a column for that, it's called username, and it has some of the right semantics (unique, indexed field). It is the arbitrary length and content restrictions that stop this from happening right now. I don't see why wanting to use email address as the unique identifier and username for a user requires any modification to the database, apart from (as I keep repeating) removing the arbitrary length and content restrictions on username. > A full and correct solution that didn't introduce dozens of new bugs is > quite hard - and I'm talking about just the code required to fix this > one feature for you, without doing anything more generally useful. > > That is why we're not going to put hacks like this in core - we would > have to support these hacks for at least 3 versions if we did. We are > interested in *removing* existing hacks from our code base, and this is > vital if Django is going to see increases in features and functionality. > We are not interested in adding more hacks. > > We also will refuse to litter our documentation with things like: "if > you've got this setting, it does this, otherwise you get this other > behaviour, and you've got to watch out for all these bugs because this > is a gross hack". > I agree with this 100%. d.c.auth needs to be fixed, not have many different settings that alter it's behaviour. Cheers Tom -- 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.
