Malcom, Google, FaceBook, and LinkedIn have been using email authentication for how long now? With the default constraints you've put on Django a developer would have to "work around" the out of the box code to make the project behave like the big 3 names on the web. In this light it sounds like the constraint is too tight and needs to be moved into an optional module not a default one. Again these sound like project specific requirements not general framework properties.
As far as your reasons go, I'm fairly sure its just as easy to change the email as it is the username, I would even argue that my username (display name) could change but my login credentials should stay the same. I currently use the same email address for multiple accounts on many Django projects using the code I pasted above, I simply use what almost every email engine today supports email[+-._] [email protected]. Looking at this objectively, I would argue the case for email authentication is strongest. I think changing the default auth module to allow both and making the current one optional would leave in place the flexibility of DJango out of the box and allow developers to constrain it on their own. Email authentication is catching on, Django should not fight the tide. You are correct, username authentication has always been around. However, the explicit banning and obfuscating of email authentication in the default module has not. That is the part that worries me, that is where things are going wrong. We're all professionals here, we all take the time to leave feedback in the hopes of improving Django. I have a sneaking suspicion that project specific requirements crept into the trunk because it was easier than patching every time. Now there is a hesitation to modify because it would affect the original project. That's not a good reason to start justifying weak requirements to the community. I would recommend re-opening the ticket and getting feedback on it from the community. -Paul On Apr 7, 5:10 pm, Malcolm Tredinnick <[email protected]> wrote: > On Tue, 2009-04-07 at 10:16 -0700, pkenjora wrote: > > Hi, > > > Why not remove the '@' filter and allow the specific project > > developer the freedom to use email as username? What was the > > reasoning behind this? > > One reason is that usernames can be made to be unique, since you're > selecting a new username and if the one you choose is already taken, you > can choose another one. You cannot, however, easily change your email > address and there are cases of different people sharing a single email > address or the same person needing/wanting to create multiple accounts. > > Another reason is likely simply historical; usernames that *aren't* > email addresses are much more readable and traditional in social-based > sites and that was what was used in the initial implementation. The > uniqueness problem mentioned above is very real, however, so Django is > protecting people from doing dumb things here. If you want to work > around that, it's possible and fairly easy, but not heavily advisable. > > > I always like Django because it didn't try to force development down > > a specific path. All developers have their own way and every project > > is unique, for a long time Django accommodated that. I'm a bit > > worried about where this is going... > > It's not "going" anywhere. The username requirements have been the same > since the very first day you used Django. Don't frame this as something > slipping out of control, please. > > > > > I'm worried that the workarounds just introduce unnecessary > > complexity. > > Almost as if you shouldn't workaround a valid constraint, isn't it? :-) > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
